| About Me Home SITE MAP SEARCH |
|
|
Structural Patterns Structural patterns deal with the problem of how classes and objects can be composed to form larger structures. There are 7 different paterns in this group.
Adapter Pattern 
The Adapter Pattern enables a system to use classes whose interfaces do not match the systems requirements.In other words this pattern enables classes with incompatible interfaces to work together. As described in the figure the client only knows the ITarget interface. The Adaptee is the class with incompatible interface. To make it usable to the client we need an Adapter which implements the ITarget interface. The adapater routes the request to the not matching request. This can be achieved by inheriting or aggregating the Adaptee. In the first case we can do overriding easily and in the second adding behaviour can be done easily. We can also make the Adapter a two way adapter, so the it can be used by both mismatching systems. This can be achieved by implementing the ITarget and also the interface of the other system. Bridge Pattern 
The Bridge Pattern deals with decoupling an abstraction from its implementation allowing them to vary independently. This is useful when we have new version of a software to replace the old but still we should be able to use the old. Now the new and the old versions are the two different implementations, which vary independently. This is similar to the Decorator Pattern as both allow different implementations of one abstraction. In a simple words, we have an abstraction of some operations. The clients access the Abstraction. Now the parts that are supposed to vary are put in the Bridge and the implementors of the bridge can vary without affecting the Abstraction / client. e.g. Let's consider the .NET Framework as Abstraction with operation as the c# compiler. Then 3.5 version of framework and 2.0 version of the framework become the Implementors and the 3.0 compilers , 2.0 compilers become the Varying Operations. In this case the envirinment variable becomes the bridge. So we can have both of them installed and we can use both. Another example is : Lets say we have a business object. We can decouple the dataobject from it to change it independently. C# feature using this pattern is the Extension methods. Composite Pattern 
The Composite Pattern arranges the structured hierarchies in such a way that the single components and group of components are treated uniformly. Some typical methods of the IComponent interface in this pattern are Add(), remove(), Display(), find() etc. This pattern can be used in conjuction with decorator, flyweight and the Visitor pattern. C# feature using this pattern is Generics (list of strings or some object , Dictionaries) The collection classes are treated in the same way making it easy for the client to use them. Decorator Pattern  The role of a decorator is to add state and behaviour to an object dynamically. So the client can use either a simple object or the decorated object without knowing their details as the both implement the same interface IComponent. In this case the Component Class is the original class. The DecoratorComponent is the the Comonent with added behaviour / state and may contain another IComponent. We can have many decorated components deriving from the same interface. The benifits of this pattern is that the decorated objects do not know each other and the original component also does not know about the decorated components. Use :
Facade Pattern 
The Facade pattern provides a unified interface to a Subsystem making it easier to use. If a subsystem is very complex we can have multiple Facades. In C# we have Namespaces which work like a facade hiding the details from the client. Every request from the client is routed to the subsystem through the Facade. The Facade has references to the real classes in the subsystem. We can make the Facade transparent or opaque. If it is transparent the client can use the subsystem directly or through facade. In case of opaque client is forced to use the facade as entry point to the subsystem. Most of the time we do not need many instances of the Facade. So it is a Singleton. If object creation for the subsystem is the main goal, then we should consider using Abstract factory pattern instead.
Flyweight Pattern: 
The flyweight pattern promotes an efficient way to share information from small objects there by reducing the storage requirements. This pattern is used when there are a large number of objects that may not fit in memory. In this case most of the state can be kept on disk or calculated at runtime.The remaining states can be factored in to smaller number of objects with shared state. This pattern works well for Text / Image processing.
Proxy Pattern
C# feature using this pattern is the Access modifiers.
|
