Sponsored Link •
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.
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.
State subclasses are defined as singletons, all instances of
StampDispenser front-end class will share the same back-end (singleton)
instances of the
Such stateless state objects, the Go4 book goes on to say, are flyweights. The
State subclasses in the stamp dispenser
example are indeed flyweights, and
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.