Comments (4) Hi
What is the basic difference between Factory Pattern and abstract factory pattern.
I have read these pattern on a book but could not understand core diffeence between them
Pls explain, or post a url
Also, When do we use which pattern.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Template Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
In template pattern we have an abstract class which acts as a skeleton for its inherited classes. The inherited classes get the shared functionality. The inherited classes take the shared functionality and add enhancements to the existing functionality. In word or power point how we take templates and then prepare our own custom presentation using the base. Template classes works on the same fundamental.
Figure ‘Template abstract class’ shows we have created a customer class ‘ClsCustomer’ which has set/get properties. Now we can inherit from this class and create add and update customer classes.
Figure: – Template abstract class
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Proxy Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Proxy fundamentally is a class functioning as in interface which points towards the actual class which has data. This actual data can be a huge image or an object data which very large and can not be duplicated. So you can create multiple proxies and point towards the huge memory consuming object and perform operations. This avoids duplication of the object and thus saving memory. Proxies are references which points towards the actual object.
Figure ‘Proxy and actual object’ shows how we have created an interface which is implemented by the actual class. So the interface ‘IImageProxy’ forms the proxy and the class with implementation i.e. ‘clsActualImage’ class forms the actual object. You can see in the client code how the interface points towards the actual object.
Figure: – Proxy and actual object
The advantages of using proxy are security and avoiding duplicating objects which are of huge sizes. Rather than shipping the code we can ship the proxy, thus avoiding the need of installing the actual code at the client side. With only the proxy at the client end we ensure more security. Second point is when we have huge objects it can be very memory consuming to move to those large objects in a network or some other domain. So rather than moving those large objects we just move the proxy which leads to better performance.
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Chain of Responsibility (COR) Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Chain of responsibility is used when we have series of processing which will be handled by a series of handler logic. Let’s understand what that means. There are situations when a request is handled by series of handlers. So the request is taken up by the first handler, he either can handle part of it or can not, once done he passes to the next handler down the chain. This goes on until the proper handler takes it up and completes the processing.
Figure: – Concept of Chain of Responsibility
Let’s try to understand this concept by a small sample example. Consider figure ‘Sample example’ where we have some logic to be processed. So there are three series of processes which it will go through. So process 1 does some processing and passes the same to process 2. Process 2 does some kind of processing and passed the same to process 3 to complete the processing activity.
Figure: – Sample example
Figure ‘class diagram for COR’ the three process classes which inherit from the same abstract class. One of the important points to be noted is that every process points to the next process which will be called. So in the process class we have aggregated one more process object called as ‘objProcess’. Object ‘ObjProcess’ points to next process which should be called after this process is complete.
Figure: – Class diagram for COR
Now that we have defined our classes its time to call the classes in the client. So we create all the process objects for process1 , process2 and process3. Using the ‘setProcess’ method we define the link list of process objects. You can see we have set process2 as a link list to process1 and process2 to process3. Once this link list is established we run the process which in turn runs the process according to the defined link list.
Figure: – COR client code
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Façade Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Façade pattern sits on the top of group of subsystems and allows them to communicate in a unified manner.
Figure: – Façade and Subsystem
Figure ‘Order Façade’ shows a practical implementation of the same. In order to place an order we need to interact with product, payment and invoice classes. So order becomes a façade which unites product, payment and invoice classes.
Figure: – Order Facade
Figure ‘façade in action’ shows how class ‘clsorder’ unifies / uses ‘clsproduct’,’clsproduct’ and ‘clsInvoice’ to implement ‘PlaceOrder’ functionality.
Figure :- Façade in action
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Decorator Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Decorator pattern allows creating inherited classes which are sum of all part of the parent. For instance figure ‘Decorator’ has class1 which has method called as ‘SomeFunction’ now we inherit and add one more method called as ‘SomeMoreFunction’. So Class2 is the addition of ‘SomeFunction’ plus ‘SomeMoreFunction’.
Figure: – Decorator
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Composite Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Composite pattern allows treating different objects in a similar fashion. Figure ‘Uniformity’ shows how different objects are called in a uniform manner.
Figure: – Uniformity
In order to treat objects in a uniformed manner we need to inherit them from a common interface. Figure ‘Common Interface’ shows the objects inheriting from a common interface.
Figure: – Common interface
Figure ‘Client code for composition’ shows how we added all the different kind of objects in to one collection and then called them in a uniform fashion.
Figure: – Client code for composition
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Bridge Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Bridge pattern helps to decouple abstraction from implementation. With this if the implementation changes it does not affect abstraction and vice versa. Consider the figure ‘Abstraction and Implementation’. The switch is the abstraction and the electronic equipments are the implementations. The switch can be applied to any electronic equipment, so the switch is an abstract thinking while the equipments are implementations.
Figure: – Abstraction and Implementation
Let’s try to code the same switch and equipment example. First thing is we segregate the implementation and abstraction in to two different classes. Figure ‘Implementation’ shows how we have made an interface ‘IEquipment’ with ‘Start()’ and ‘Stop()’ methods. We have implemented two equipments one is the refrigerator and the other is the bulb.
Figure :- Implementation
The second part is the abstraction. Switch is the abstraction in our example. It has a ‘SetEquipment’ method which sets the object. The ‘On’ method calls the ‘Start’ method of the equipment and the ‘off’ calls the ‘stop’.
Figure: – Abstraction
Finally we see the client code. You can see we have created the implementation objects and the abstraction objects separately. We can use them in an isolated manner.
Figure :- Client code using bridge
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Fly Weight Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Fly weight pattern is useful where we need to create many objects and all these objects share some kind of common data. Consider figure ‘Objects and common data’. We need to print visiting card for all employees in the organization. So we have two parts of data one is the variable data i.e. the employee name and the other is static data i.e. address. We can minimize memory by just keeping one copy of the static data and referencing the same data in all objects of variable data. So we create different copies of variable data, but reference the same copy of static data. With this we can optimally use the memory.
Figure: – Objects and common data
Below is a sample C# code demonstration of how flyweight can be implemented practically. We have two classes, ‘clsVariableAddress’ which has the variable data and second ‘clsAddress’ which has the static data. To ensure that we have only one instance of ‘clsAddress’ we have made a wrapper class ‘clsStatic’ and created a static instance of the ‘clsAddress’ class. This object is aggregated in the ‘clsVariableAddress’ class.
Figure: – Class view of flyweight
Figure ‘Fly weight client code’ shows we have created two objects of ‘clsVariableAddress’ class, but internally the static data i.e. the address is referred to only one instance.
Figure: – Fly weight client code
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Adapter Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Many times two classes are incompatible because of incompatible interfaces. Adapter helps us to wrap a class around the existing class and make the classes compatible with each other. Consider the below figure ‘Incompatible interfaces’ both of them are collections to hold string values. Both of them have a method which helps us to add string in to the collection. One of the methods is named as ‘Add’ and the other as ‘Push’. One of them uses the collection object and the other the stack. We want to make the stack object compatible with the collection object.
Figure: – Incompatible interfaces
There are two way of implementing adapter pattern one is by using aggregation (this is termed as the object adapter pattern) and the other inheritance (this is termed as the class adapter pattern). First let’s try to cover object adapter pattern.
Figure ‘Object Adapter pattern’ shows a broader view of how we can achieve the same. We have a introduced a new wrapper class ‘clsCollectionAdapter’ which wraps on the top of the ‘clsStack’ class and aggregates the ‘push’ method inside a new ‘Add’ method, thus making both the classes compatible.
Figure: – Object Adapter pattern
The other way to implement the adapter pattern is by using inheritance also termed as class adapter pattern. Figure ‘Class adapter pattern’ shows how we have inherited the ‘clsStack’ class in the ‘clsCollectionAdapter’ and made it compatible with the ‘clsCollection’ class.
Figure :- Class adapter pattern
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Visitor Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Visitor pattern allows us to change the class structure with out changing the actual class. Its way of separating the logic and algorithm from the current data structure. Due to this you can add new logic to the current data structure with out altering the structure. Second you can alter the structure with out touching the logic.
Consider the below figure ‘Logic and data structure’ where we have a customer data structure. Every customer object has multiple address objects and every address object had multiple phone objects. This data structure needs to be displayed in two different formats one is simple string and second XML. So we have written two classes one is the string logic class and other is the XML logic class. These two classes traverse through the object structure and give the respective outputs. In short the visitor contains the logic.
Figure: – Logic and data structure
Let’s take the above customer sample and try to implement the same in C#. If you are from other programming you should be able to map the same accordingly. We have created two visitor classes one which will be used to parse for the string logic and other for XML. Both these classes have a visit method which takes each object and parses them accordingly. In order to maintain consistency we have implemented them from a common interface ‘IVisitor’.
Figure :- Visitor class
The above defined visitor class will be passed to the data structure class i.e. the customer class. So in the customer class we have passed the visitor class in an ‘Accept’ function. In the same function we pass this class type and call the visit function. The visit function is overloaded so it will call according to the class type passed.
Figure: – Visitor passed to data structure class
Now every customer has multiple address objects and every address has multiple phone objects. So we have ‘objAddresses’ arraylist object aggregated in the ‘clsCustomer’ class and ‘objPhones’ arraylist aggregated in the ‘clsAddress’ class. Every object has the accept method which takes the visitor class and passes himself in the visit function of the visitor class. As the visit function of the visitor class is overloaded it will call the appropriate visitor method as per polymorphism.
Figure: – Customer, Address and phones
Now that we have the logic in the visitor classes and data structure in the customer classes its time to use the same in the client. Below figure ‘Visitor client code’ shows a sample code snippet for using the visitor pattern. So we create the visitor object and pass it to the customer data class. If we want to display the customer object structure in a string format we create the ‘clsVisitorString’ and if we want to generate in XML format we create the ‘clsXML’ object and pass the same to the customer object data structure. You can easily see how the logic is now separated from the data structure.
Figure: – Visitor client code
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
Comments Off This article is written under ‘Quick and Short’ edition. In this article I will explain about Strategy Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Strategy pattern are algorithms inside a class which can be interchanged depending on the class used. This pattern is useful when you want to decide on runtime which algorithm to be used.
Let’s try to see an example of how strategy pattern works practically. Let’s take an example of a math’s calculation where we have strategies like add and substract. Figure ‘Strategy in action’ shows the same in a pictorial format. It takes two numbers and the depending on the strategy it gives out results.So if it’s an addition strategy it will add the numbers, if it’s a substraction strategy it will give the substracted results. These strategies are nothing but algorithms. Strategy pattern are nothing but encapsulation of algorithms inside classes.
Figure: – Strategy in action
So the first thing we need to look in to is how these algorithms can be encapsulated inside the classes. Below figure ‘Algorithm encapsulated’ shows how the ‘add’ is encapsulated in the ‘clsAddStatergy’ class and ‘substract’ in the ‘clsSubstractStatergy’ class. Both these classes inherit from ‘clsStratergy’ defining a ‘calculate’ method for its child classes.
Figure: – Algorithms encapsulated
Now we define a wrapper class called as ‘clsMaths’ which has a reference to the ‘clsStatergy’ class. This class has a ‘setStatergy’ method which sets the strategy to be used.
Figure: – Strategy and the wrapper class
Below figure ‘Strategy client code’ shows how the wrapper class is used and the strategy object is set on runtime using the ‘setStatergy’ method.
Figure: – Strategy client code
—————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
Comments Off This article is written under ‘Quick and Short’ edition. In this article I will explain about State Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
State pattern allows an object to change its behavior depending on the current values of the object. Consider the figure ‘State pattern example’. It’s an example of a bulb operation. If the state of the bulb is off and you press the switch the bulb will turn off. If the state of bulb is on and you press the switch the bulb will be off. So in short depending on the state the behavior changes.
Figure: – State pattern example
Now let’s try to implement the same bulb sample in C#. Figure ‘State pattern in action’ shows both the class and the client code. We have made a class called as ‘clsState’ which has an enum with two state constants ‘On’ and ‘Off’. We have defined a method ‘PressSwitch’ which toggles its state depending on the current state. In the right hand side of the same figure we have defined a client which consumes the ‘clsState’ class and calls the ‘PressSwitch()’ method. We have displayed the current status on the textbox using the ‘getStatus’ function.
When we click the press switch it toggles to the opposite state of what we have currently.
Figure: – State pattern in action
—————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Observer Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Observer pattern helps us to communicate between parent class and its associated or dependent classes. There are two important concepts in observer pattern ‘Subject’ and ‘Observers’. The subject sends notifications while observers receive notifications if they are registered with the subject. Below figure ‘Subject and observers’ shows how the application (subject) sends notification to all observers (email, event log and SMS). You can map this example to publisher and subscriber model. The publisher is the application and subscribers are email, event log and sms.
Figure: – Subject and Observers
Let’s try to code the same example which we have defined in the previous section. First let’s have a look at the subscribers / notification classes. Figure ‘Subscriber classes’ shows the same in a pictorial format. So we have a common interface for all subscribers i.e. ‘INotification’ which has a ‘notify’ method. This interface ‘INotification’ is implemented by all concrete notification classes. All concrete notification classes define their own notification methodology. For the current scenario we have just displayed a print saying the particular notification is executed.
Figure: – Subscriber classes
As said previously there are two sections in an observer pattern one is the observer/subscriber which we have covered in the previous section and second is the publisher or the subject.
The publisher has a collection of arraylist which will have all subscribers added who are interested in receiving the notifications. Using ‘addNotification’ and ‘removeNotification’ we can add and remove the subscribers from the arraylist. ‘NotifyAll’ method loops through all the subscribers and send the notification.
Figure: – Publisher/Subject classes
Now that we have an idea about the publisher and subscriber classes lets code the client and see observer in action. Below is a code for observer client snippet. So first we create the object of the notifier which has collection of subscriber objects. We add all the subscribers who are needed to be notified in the collection.
Now if the customer code length is above 10 characters then tell notify all the subscribers about the same.
Figure: – Observer client code
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
This article is written under ‘Quick and Short’ edition. In this article I will explain about Memento Design Patterns.
Read more Quick and Short articles.
Read more about design patterns [Factory], [Abstract Factory], [Singleton], [Builder], [Prototype], [Adapter], [Bridge], [Composite], [Decorator], [Facade], [Proxy], [Flyweight], [Chain of Responsibility], [Command], [Iterator], [Mediator], [Memento], [Observer], [State], [Strategy], [Visitor], [Template Method], [Interpreter]
Memento pattern is the way to capture objects internal state with out violating encapsulation. Memento pattern helps us to store a snapshot which can be reverted at any moment of time by the object. Let’s understand what it means in practical sense. Consider figure ‘Memento practical example’, it shows a customer screen. Let’s say if the user starts editing a customer record and he makes some changes. Later he feels that he has done something wrong and he wants to revert back to the original data. This is where memento comes in to play. It will help us store a copy of data and in case the user presses cancel the object restores to its original state.
Figure: – Memento practical example
Let’s try to complete the same example in C# for the customer UI which we had just gone through. Below is the customer class ‘clsCustomer’ which has the aggregated memento class ‘clsCustomerMemento’ which will hold the snapshot of the data. The memento class ‘clsCustomerMemento’ is the exact replica ( excluding methods ) of the customer class ‘clsCustomer’. When the customer class ‘clsCustomer’ gets initialized the memento class also gets initialized. When the customer class data is changed the memento class snapshot is not changed. The ‘Revert’ method sets back the memento data to the main class.
Figure: – Customer class for memento
The client code is pretty simple. We create the customer class. In case we have issues we click the cancel button which in turn calls the ‘revert’ method and reverts the changed data back to the memento snapshot data. Figure ‘Memento client code’ shows the same in a pictorial format.
Figure: – Memento client code
——————————————————————————————————————————————————————
Readers are requested to add comment, and add more information in case they want.
Read more Quick and Short articles.
51 | Unique Visitors |
