To control access to an object, provide a surrogate or placeholder (proxy) for it. As a mostly used strategy, Proxy can defer the creation and initialization of the object until it is on demand.
Structure:
Similar to adapter, client includes an object of proxy to access, and proxy includes a real object that proxy represents.
Difference from Adapter:
Adapter provides a different interface to the object it adapts. In contrast, Proxy provides the same interface as its subject. As a protection of real object, Proxy can refuse to perform an operation that the subject will perform.
Example:
http://www.javaworld.com/javaworld/jw-02-2002/jw-0222-designpatterns.html
Reference:
Book: (GoF)Design Patterns
http://en.wikipedia.org/wiki/Proxy_design_pattern
http://www.inf.bme.hu/ooret/1999osz/DesignPatterns/Proxy4/
http://alumni.media.mit.edu/~tpminka/patterns/Proxy.html
]]>
Encapsulate a set of objects which interact with each other. The benefit to do this is keeping objects from communicating with each other directly. All the messages between objects should be sent to mediator at first and then mediator will control and coordinate those interaction. Also, mediator can handle external interaction request and decide which object to response the external request.
Structure:
star topology: Mediator class is as a hub which connects to a set of classes (colleague classes).
Difference from Facade Pattern:
Facade differs from Mediator in that it abstracts a subsystem of objects to provide a more convenient interface. Its protocol is unidirectional. That is, Facade objects make requests of the subsystem classes but not vice versa. In contrast, Mediator enables cooperative behavior that colleague objects don't or can't provide, and the protocol is multidirectional.
reference:
Gamma, E., R. Helm, R. Johnson, J. Vlissides (1995). Design Patterns. Addison Wesley. ISBN 0.201-63361-2
http://sern.ucalgary.ca/courses/seng/443/W02/assignments/Mediator/
http://my.execpc.com/~gopalan/design/behavioral/mediator/mediator.html
]]>
Case study:
Compiler subsystem
Structure:
-- The facade and backend classes(subsystem classes) are in a separate package from the client.
-- The backend API is package-private
-- The facade API is public.
Implementation:
consider following two issues when implementing a facade:
-- Reducing client-subsystem coupling.
-- Public versus private subsystem classes.
reference:
http://www.allapplabs.com/java_design_patterns/facade_pattern.htm
]]>
Structure:
Typically, there will be a parameter to pass original object to decorator object in its constructor, then decorator can implement additional functions within its own interface and apply to original object.
when to use:
-- when subclassing is not avaible
-- when the responsibilities (for different functions) are required flexiable and dynamical
-- can not predict combination of extending functionality. (We can not design subclasses for all combination of potential additional functionalities at compile time)
reference:
Book: Design Pattern (GoF)
http://en.wikipedia.org/wiki/Decorator_pattern
]]>
Structure:
The composite object contains other primitive objects(or say Components), and has the same operation as in those primitive objects. Thus we can operater the composite object with the same operations as a whole. Or in other word, composite object is a container of primitive ojects and itself is derived from same base (abstract) class as primitives, so that it can have same operations as primitives. Actually, we can say that the abstract class represents both primitives and their containers
Implementation:
-- Extend a base class that represents primitive objects. And the same operation(override function) will be implemented by iterating over that collection and invoking the appropriate method for each component in the collection.
-- Add & Remove function (for component collection) will be defined in base class, though it is meaninglessful for leaf classes.
reference:
http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns.html
http://www.codeproject.com/useritems/Composite.asp
example:
http://java.sun.com/blueprints/patterns/CompositeView.html
]]>
To think about this situation that an abstract class has two categories of inheritance. Each category can be a seperate hierarchical inheritance聽tree, if we聽derive all the subclasses from the abstract class, it will make complex聽when we need to get some sub-classes that contains facades from two categories. So we need seperate those subclasses into differenct categories, typically one into implementation hierarchy while another into abstraction hierarchy which can聽employ subclasses of implementation hierarchy. No matter how, the relationship between different hierarchies is a bridge. From this point, the bridge pattern design lets different hierarchies can evolve seperately.
The structure of the Adapter Pattern (object adapter) may look similar to the Bridge Pattern. However, the adapter is meant to change the interface of an existing object and is mainly intended to make unrelated classes work together.
reference:
book:"Design Patterns鈥?Gamma et al.
http://en.wikipedia.org/wiki/Bridge_pattern
http://www.c-sharpcorner.com/Language/BridgePatternsinCSRVS.asp
http://www.codeproject.com/gen/design/bridge.asp
]]>
Object Adapter:
-- use compositional technique
-- by composing interface B's instance within interface A (target interface, adapter) and implement interface A in terms of B's interface(adaptee). Interface A is Object Adapter which enables the client (the class or object to use Interface A) and the adaptee(Interface B) to be completely decoupled from each other.
Class Adapter:
-- use multiple inheritance
-- Notice that Java is not supporting true multiple inheritance, there must be one inheritance is from Java Interface(implementation) not Java class. So take above Object Adapter as example, if client want to access Interface B, the adpater Interface A will inherit from class(Class Adapter) which Client can access, and inherit the implementation of Interface B(Adaptee). So Interface A can have a funtion to call functions in Interface B, and so that Interface will not have an object of Interface B, that is the difference from Object Adapter method.
reference:
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/adapter.htm
]]>
reference:
http://gsraj.tripod.com/design/creational/factory/factory.html
http://en.wikipedia.org/wiki/Factory_method_pattern
http://www.developer.com/java/other/article.php/626001
http://www.javacamp.org/designPattern/factory.html
]]>