|Provide three "classes": an interface, an abstract
class, and a default implementation. [Design Pattern]
You are developing a framework of cooperating classes.
- You want to make things easy for the user, so you want to provide
- But you want your design clean, and you want the user to provide
implementations where appropriate.
Provide three "classes":
- An interface (fully abstract class), to keep the design clean.
- An abstract class (that conforms to the interface), that implements the
"bookkeepping part of the class, but has abstract methods for the
- A fully-implemented class (probably a subclass of the abstract class,
definitely conforming to the interface). This should provide a useful default
This gives the user several places to "plug in." The first cut (or a naive
programmer) can work with the default implementation. A more sophisticated
implementation can extend the abstract class, and avoid copying data into and
out of the default implementation. An implementation for which the abstract
version's bookkeepping is too much overhead can replace everything. Finally, the
interface provides a barrier to ensure clients don't care (depend on) which
actual types they're working with.
- The Swing
libraries for Java use this pattern. For instance, TableModel provides the
interface. AbstractTableModel handles the change notification, and lets you
wrap your own table structure with it. DefaultTableModel provides a table that
uses Vector for storage.