126
C HAPTER 10
E VOLVING FRAMEWORKS
framework, it was just misclassified (from your perspective) by the framework developers. Creation If your framework publishes any concrete classes you need to decide how clients can instantiate them. As with the other framework design decisions, you need to balance generality, complexity, ease of learning, and ease of evolution in your choice of instantiation style. The four styles described here are no client instantiation, constructors, factory methods, and factory objects. These styles are not mutually exclusive. You may use more than one style for a given object or you may use different styles for different parts of the framework. No Creation The simplest and least powerful option is to prohibit clients from creating framework objects directly. The SWT event example cited above demonstrates this. By always constructing events inside the framework, the framework developers can guarantee that events are well formed. The framework code may be simpler if it can assume invariants about events. The limitation of not allowing clients to create instances of framework classes is that it precludes legitimate uses of the classes the framework developer didn’t anticipate. For very difficult programming tasks where any reduction of complexity would be welcome, eliminating the possibility of clientcreated objects may be a good choice. The value of a framework is often one not originally expected by the framework developers. Cutting off the chance for unexpected uses reduces the chance of finding additional valuable uses of the framework. Constructors Offering clients the ability to create objects through constructors is a simple option but one that creates substantial constraints on future change. When you publish a constructor, you are promising that the name of the class, the parameters required for creation, the package of the class, and (most constraining of all) the concrete class of the returned object won’t change. Most of the Java libraries offer creation through constructors. Once Sun published that lists are created by saying new ArrayList() they were committed to keeping a class named ArrayList in the java.util package without changing the concrete class returned. These are all substantial design constraints to maintain for the indefinite future, limiting the kind of changes Sun can make. The advantage of representing object creation as a constructor is that it is simple and clear for clients. If clients need an easy-to-use creation interface and