Methodological Unimplementation

Methodological Unimplementation

Designing a class for an application involves identifying and defining its behavior and state. The behavior is defined in the form of methods that the class provides. Often, in the design process, the need for a method is identified, but the implementation is deferred to a later stage in the development process. The implementation may be provided in a later version of the software or by a derived class.

For example, consider the following class:

 public class NotCompletelyImplemented {  public implementedMethod() {    // Implementation details      }  public void unimplementedMethod ()  {    System.out.println("Method unimplemented by slacker");  }}

This code illustrates one way of deferring the implementation of the method. The first method, implementedMethod(), has actual implementation code. The second method, unimplementMethod(), just prints an error to the console. When actual code for the second method is available, it can replace the print statement.

Java’s exception mechanism may provide a more elegant way of accomplishing this task. An application-wide unchecked exception should be declared as follows:

 public class UnimplementedMethodException {  public UnimplementedMethodException () {    // Code to handle an unimplemented method exception.  }}

Now the unimplementException() method in the earlier code excerpt should be changed to:

 public void unimplementMethod () {  throw UnimplementedMethodException();}

All such unimplemented methods can be coded in this fashion. The exception will either be caught in the calling method, or propagated up a level. The advantage of this approach is that if you want to handle the fact that an unimplemented method was called, you can handle it in a central point in your application, for example, in the UnimplementedMethod class.


Share the Post: