Design Patterns

• Guideline: Be aware of composition and inheritance in design patterns.
• Many design patterns are: composition for a particular reason
• Observer: Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
• Adapter: Convert the interface of a class into another interface the client expects
• Decorator: Attach additional responsibilities to an object dynamically
• Proxy: Provide a surrogate or place holder for another object to control access to it
• State: Allow an object to alter its behavior when its internal state changes
• Command: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
• Strategy: Define a family of algorithms, encapsulate each one, and make them interchangable.
• Inheritance shows up as tight-knit families of States, Strategies, etc...
• Use Iterators to provide access to the elements of a collection.
• Template method is delegation to a subclass.

Difference between decorator and proxy is that I usually get an object that is already a proxy to something else (because the intent is that the service provider wants to control my access to the back-end object), but I usually add decorations myself to a back-end object.

Ideas for examples: The actual stamp dispenser. A bicycle computer. Stack, Queue, and Dequeue. For decorator, use Accounts, with OverdraftAccount, FeeAccount (charges fees on withdrawal and or deposit), LinkedAccount (transfers funds from another account on overdraft), MatchingAccount (matches deposited funds until a reservoir is exhausted, but can replenish the reservoir): Consider all the combinations: OverdraftMatchingAccount, OverdraftFeeAccount, LinkedFeeAccount, FeeLinkedAccount, FeeLinkedMatchingAccount, and so on. (Don't attempt to show these combinations in a hierarchy, just list them. "You get an exploding hierarchy." Could also have a MinimumBalanceAccount that forces that you keep a minimum balance in the account, but maybe that's not such a good one because dropping below the min usually results in a fee, not ... hey! maybe that's my notification example for sig of interfaces.

Show how inner classes actually get compiled in Iterator example.

Go throught remote proxy (over the net), virtual proxy (lazy initialization), protection proxy (minimize access allowed, as in immutable or thread safe collection wrappers, smart reference (soft reference)

The difference between Proxy and Decorator is that the back-end is already proxied by a front-end when the client gets ahold of it. The client can't get to the back-end, only the front-end. By contrast, it is the client that usually connects front-ends and back-ends in a decorator scenario. Though both are composition (with some common interface between front and back ends), the intent is different.

May want to add Composite in the mix.

Adapter is important in the sense that it points out that the interfaces of objects in a composition relationship need not be compatible. More flexible than inheritance.

I grabbed this from the bottom of the state pattern one. Use it here as the first example of composition for a purpose in design patterns.

Figure 4-3. Composition and the state pattern.

As shown in Figure 4-3, the state pattern is yet another example of using composition to achieve a particular goal. In this case the front-end object delegates responsibility to any of several back-end state objects, primarily to transform a single, difficult to maintain class into many easier to maintain classes. In the state pattern, the back-end state objects are unknown to the clients of the front-end. The back-end objects are purely creatures of the front-end object's implementation. The back-end object is varied throughout the life of the object. Often, the back-end objects are shared among multiple front-end objects.

This last aspect of the state pattern's use of composition is mentioned by the Go4 book. One benefit of the state pattern, says the Go4, is that if the state objects are stateless, they can be shared. All four concrete State subclasses in the StampDispenser example are stateless, which in turn means they can be shared. And in fact they are shared. Because the State subclasses are defined as singletons, all instances of the StampDispenser front-end class will share the same back-end (singleton) instances of the State subclasses. Such stateless state objects, the Go4 book goes on to say, are flyweights. The four State subclasses in the stamp dispenser example are indeed flyweights, and Has0State serves as a flyweight example in Guideline 4. (May want to emphasize that state objects need not be stateless.)

The state pattern also involves inheritance, because the concrete state subclasses must all inherit some common interface. In Java, the interface can be inherited from either a superclass or superinterface. In the stamp dispenser example, all concrete state classes subclass the abstract class State, forming a tight knit family of states. This very family of states appears in Guideline ?, as an example of when to use an abstract class over an interface.