Solutions to Creation Pattern Lab

1. Factory Pattern

People had the most trouble with this one. The Factory Method Pattern is NOT the same as the Abstract Factory Pattern. The former decouples behavior of an object from is creation. The latter decouples construction of an assembly from the construction of its components. Remember that!

Here's the simple design:

Note that most of the work done is in the reusable Interpreter class. The Interpreter encapsulates knowledge of how slaves behave: start, stop, pause, resume, etc. It also implements the interpreter's control loop. The only thing it doesn't know is how to create slaves. That's why makeSlave is an abstract factory method. NTInterpreeter only needs to implement makeSlave.

If you are wondering why you lost points, recall the Open-Closed Principle: systems/components should be open to extension but closed to modification. Now ask yourself this: What must my customer do to use this code with another set of slaves? Does he need to modify existing code? If your answer is "yes", then start deducting points.

The reusable part of my framework Interpreter and Slave) is in Interpreter.java.

The customization is in NTInterpreter.java.

2. Singleton vs. Utility

3. Interning

There are two approaches to this problem: either the arithmetic methods are in the Int class or they are not. In my TestCalculator.java I have included the add method in Int, but not the mul method so that you can decide which approach is better. Remember, the way to decide is to ask yourself which approach is easier for clients of the Int class, like Calc.

Either way, the basic implementation of Int is the same. It has a private constructor and a static makeInt function that first searches a cache or repository to see if the Int has already been created. If so, then that Int is returned, otherwise a new Int is created, added to the repository, then returned.

4. Abstract Factory

Again there was a lot of misunderstanding on this one. Here's a Java template for the Abstract Factory Pattern:

interface Factory {
Component1 makeComponent1();
Component2 makeComponent2();
Component3 makeComponent3();
}

class Assembly {
private Component1 a;
private Component2 b;
private Component3 c;
public Assembly(Factor f) {
a = f.makeComponent1();
b = f.makeComponents();
c = f.makeComponent3();
// now "connect" a, b, & c as needed
}
// etc.
}

As mentioned earlier, this pattern decouples the task of making an assembly from the task of making the assemblies components. The construction of the assembly is embodied in the Assembly constructor. "Connecting" the components might be very difficult. Consider a constructor for a JPanel subclass that must layout all of the controls. These constructors can get very large. We don't want to have to reimplement the assembly constructor just because the underlying components change (provided the new components have the same behavior as the old components.) In this pattern the abstract factory embodies the construction of the components.

Although noit a perfect fit, the testing framework is a pretty good place to use this pattern. Assembling and giving a test is already difficult, even before one thinks up the question. Also, the work of assembling and running a test is pretty much the same whether it's a math test or a history test.

In this cast Test is our assembly. It's an assembly of questions. The Teswt constructor takes an TestFactory as input and uses this to create the questions. Note: this should not be done inside run. For one thing, it's inefficient sunce the test must be constructed each time it is run.