Beautiful Code [124]
[]Effective Java, Joshua Bloch, Prentice Hall PTR, 2001.
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Krzysztof Cwalina and Brad Abrams, Addison-Wesley Professional, 2005.
Let's look at an example outside of FIT that shows those rules in action: the JavaMail API.
If you want to receive mail using JavaMail, you have to get a reference to a Session object. Session is a class that has a static method named getDefaultInstance:
package javax.mail;
public final class Session
{
...
public static Session getDefaultInstance(Properties props);
...
public Store getStore( ) throws NoSuchProviderException;
...
}
The Session class is final. In Java, this means that we cannot create subclasses of Session. Furthermore, Session doesn't have a public constructor, so we can't create an instance ourselves; we have to use that static method to get an instance.
Once we have a session, we can use the getStore method to get a Store: an object that contains folders of received mail and a few other helpful things.
Store is an abstract class. The JavaMail framework supplies a couple of subclasses of Store, but as users we don't have to care which one is returned to us; we just accept it and use it to get our mail. If we want to be notified when the framework changes the store, we can register a listener on the store instance using this method:
public abstract class Store extends javax.mail.Service {
...
public void addStoreListener(StoreListener listener);
...
}
This little portion of the JavaMail framework epitomizes traditional framework style. The Session class is declared as final to prevent subclassing. JavaMail also uses an abstract class, Store, to provide a point of extension: there can be many kinds of stores.
However, Store is a guarded extension point. There is no programmatic way to have Session return a different Store object. The returned Store can be configured, but not in the code. The framework has locked down that choice.
On the other hand, you can register a listener on the Store. This listener is a little "hook point" defined by the framework developers so that users can receive notifications about things that happen on the store without having to subclass Store themselves.
All in all, the Java Mail API protects itself very well. You have to go through a well-defined sequence of steps to use it, and the framework developers have "cover" for future change; they can go back and change anything they want to in the internals of the Session class without worrying about someone subclassing and overriding particular pieces of it.
Framework for Integrated Test: Beauty Through Fragility > An Open Framework
6.3. An Open Framework
FIT is a very different kind of framework. You might have noticed from the UML diagram in Figure 6-3 that nearly everything in the core framework is public, even the data. If you glance though the code of other popular frameworks, you'll find nothing quite like it. How could this possibly work? It works because FIT is an example of an open framework. It doesn't have a small set of designed extension points; the entire framework was designed to be extensible.
Let's take a look at the Fixture class. Clients of the Fixture class use it in a very direct way. They create an instance of Fixture, create a parse tree for an HTML document using Parse, and then pass the tree to the doTables method. The doTables method then calls doTable for each table in the document, passing along the appropriate parse subtree.
The doTable method looks like this:
public void doTable(Parse table) {
doRows(table.parts.more);
}
And the method it calls, doRows, looks like this:
public void doRows(Parse rows) {
while (rows != null) {
doRow(rows);
rows = rows.more;
}
}
The doRow method, in turn, calls doCells:
public void doRow(Parse row) {
doCells(row.parts);
}
And the sequence bottoms out in a