Decorator pattern
Use the decorator pattern when:
You have
- - An existing component class that may be unavailable for subclassing
You want to
- -Attach additioanl state or behaviour to an object dynamically (or remove it ?????????)
- -make changes to some objects in a class without affecting others
- -avoid subclassing because too many classes would result (hmmmmmmm, sounds like bullshit to me).
But consider using instead
- -The Adapter pattern, which sets up an interface between different classes
- -The Composites patter, which aggregates an object without also inheriting its interface
- -The Proxy pattern, which specifically controls access to objects.
- -The Strategy pattern, which changes the original object rather than wrapping it.
example
I/O Apis of C# , Stream, BufferedStream, FileStream, MemoryStream, NetworkStream, ,CryptoStream
Proxy Pattern
ADO.Net database connection classes are effectively proxies.
Often found in image-drawing systems, where the proxy places a placeholder on the screen and then activates a real drawer to fetch and render the image. And similary to initiate the buffering associated with video streaming.
Both the adapter and proxy patterns consitute a thin layer around an object. However the adapter provides a different interface for an object, while the proxy provides the same interface, but interposes itself where it can postpon processing or data transmission effort.
A decorator also has the same interface as the object it surrounds, but its purpose is to add additional funtoin to the original object. A proxy, by contrast, controls access to the contained class.
Proxies like decorators forward requests on to another object. The proxy relationship is set up at design time (compile time) , decorators on the other hand can be added dynamically (what about dynamic proxies??????????).
Remote
Virtual
Authentication
(Dynamic ??????????)
Use the proxy pattern when
you have objects that
- -are expensive to create
- -need access control
- -access remote sites
need to perform some action whenever they are accessed
you want to
- -create objects only when their operations are requested
- -perform checks or housekeeping on objects whenever accessed
- -have a local object that will refer to a remote object
- -implement access rights on objects as their operations are requested
Strategy Pattern
Use the strategy pattern when
- -Many classes differ only in their behaviour
- -There are different algorithms for a given purpose, and the selction criteria can be codified
- -The algorithm uses data which the client should not have access to (hmm, what does this mean????????????)
Bridge Pattern
Use the bridge pattern to vary not only your implementations but also your abstractions.
Iterator Pattern
Composite Pattern