Construct classes from the outside in
When experimenting with the design of a new class, it's very helpful
to approach the task from the point of view of the caller:
Much of design is summed up simply as:
the quality of the final design will be higher, since there is more feedback
from use cases
the class is often constructed significantly faster, since discovery
of poor design decisions usually happens much earlier
The critical step seems to be the second. The best techniques are those
which discover the errors the fastest. Coding "from the outside in"
seems to perform very well in this regard.
make your best guess
find and fix the errors
Constructing a non-private method from the outside in might involve
In effect, such techniques use the programming language itself as a design tool.
write some code from the point of view of the caller
make the code compile by providing a simple stub implementation of the
method you are designing. For a
void method, such a stub is
simply an empty method. For a method which has a return value, such a stub
might simply return
false, or an empty
experimenting with different designs is simple at this point, since
the amount of calling code is minimal, and the implementations are toys
correctness of method name and return type are determined by the needs
of the caller
correctness of arguments seems to be determined more by the needs of the
implementation, not the caller
is the return type correct? This is an important item, since changes
in return type will often have large ripple effects in the caller.
is the method intelligible at the point of call?
when the design is more or less stable, write the javadoc of the method as
the formal specification of the contract between
the method and its callers. Often, this will also help clarify details
and border cases.
finally, replace the stub implementation with a real implementation, and
See Also :