At times we may need to deal with different objects performing different tasks based on a defined workflow. There may be a need for delegation and processing the tasks between various objects.
Such kind of problems can be solved by the "Chain of Responsibility" pattern.
Consider a situtation where we may need to handle the bank loan approval process.A bank may have approving authorties at various levels like Manager,Director,President,etc.
The approval limit may vary across the levels. For Example, a Manager has a maximum approval limit of Rs.10,000, for a Director it will be RS.50,000 and for a President it will be more than RS.50,000.
Whenever a Manager receives a request for approving Rs.1,00,000, he/she will delegate the request to their immediate predecessor. Here it will be delegated to the Director. Since, the requested approval amount exceeds the Directors limit, it will be furthur delegated to the President. The President can approve the amount.
Here, the responsibility of approval is being delegated to various persons based on their nature. This can be termed as "Chain Of Responsibility".
Please refer the below class diagram for more details on this pattern,
Following code snippet can provide a clear idea over the implementation,
public void approve(double amount) {
System.out.println("Manager checking the limits");
if(amount<=10000)
System.out.println("Approved!");
else{
System.out.println("Approval Limit Exceeds! Delegating to "+predecessor);
predecessor.approve(amount); //Delegating the responsibility to the predecessor
}
Code snippet for the client could be,
Approver president=new President(null);
Approver director=new Director(president);
Approver manager=new Manager(director);
manager.approve(200000);
Proxy pattern filters and customizes the data you want from the main big subject. Assume, we have a subject with nearly 200 properties into it. But frequently we may need 10 or 20 of them.
So, we will end-up in creating a proxy for the subject by filtering the 10 or 20 properties alone from the main subject.
Whenever we need those properties we may access the proxy instead of the main subject.
This will help us to get way from creating costly objects and business calls.
For example, Student will be our subject which contains data like attendance, marks, age,etc. But we may not interest in all the data except the attendance information. Instead of using the entire Student object, we will create a Proxy to the Student which provides the attendance details alone.
Proxy can add more functionalties before or after getting the attendance details from the Student Object.
Following diagram explains this pattern a bit more,
We can use the proxy object whenever we need to process the attendance for the student.
This proxy will internally communicate with the Student object with a singleton pattern.
Proxy Code snippet in Client:
Student abc=new ProxyStudent();
Student def=new ProxyStudent(); //Create Proxies for Student
In the Proxy Class,
public String getAttendance() {
if(realStudent==null){ //Ensure singleton object for the Subject
realStudent=new RealStudent();
}
return realStudent.getAttendance();
}
Have you ever imagined that you are standing in between a huge array of army in the battlefield? The army may consists of horses,elephants,chariots and big mass of soldiers.
Seeing such a scene itself brings a mammoth outlook before your eyes.
How about drafting a design to accomodate the army?
An army may contain thousands/lakhs of soldiers. Think about creating an object for each and every soldier. We have elephants,horses,chariots and soldiers on foot assembled in a disciplined structure with their positions.
How about designing an order of positions for this army?
At first sight, it really looks like a costly effort. Because, we will end up in creating lakhs/thousands of objects to represent the army.
A solution to this type of problems could be a Flyweight Pattern. It helps us to minimize the number of objects created by generalizing the common pattern observed
among them.
This pattern is a collaboration of Factory Method and Singleton design patterns.
Now, let us think a way to simplify the object structure by recognizing the patterns from the army. We can identify some classifications among the soldiers like elephants, horses, chariots and normal soldiers. But, we need to maintain position for each of them.
First, we generalize the soldiers based on their nature, which could be the intrinsic property.So, we will end up in creating just four objects(chariots, elephants, horses, soldiers).
Then, the position to which they need to occupy ,could be more dynamic and explicitly specified.
For example, let us consider we have 1000 soliders in an army.
It consists of 100 chariots, 200 Elephants, 200 Horses, 500 Soldiers and they were positioned in rows 4,3,2 and 1 respectively.
We construct 4 objects for the types of soldiers in an army and we dynamically initialize their position in the battlefield.
Following design explains this approach in a better way,
Soldier is the Flyweight object constructed using the SoldierFactory which is a Flyweight Factory. This flyweight object is a singleton for each and every soldier type.
After receiving the flyweight object client can decide where to position each and every soldier.
FlyweightFactory Code snippet,
private static HashMap<String,Soldier> soldiers=new HashMap<String,Soldier>();
public static Soldier getSoldier(String type){
Soldier soldier=soldiers.get(type);
if(soldier==null){
soldier=new Soldier(type);
soldiers.put(type, soldier);
}
return soldier;
}
Client code,
Soldier soldier;
for(int i=1;i<=1000;i++){
if(i<=100){
soldier=SoldierFactory.getSoldier("Chariot");
soldier.setPosition(4);
}
else if(i<=300){
soldier=SoldierFactory.getSoldier("Elephant");
soldier.setPosition(3);
}
else if(i<=500){
soldier=SoldierFactory.getSoldier("Horse");
soldier.setPosition(2);
}
else{
soldier=SoldierFactory.getSoldier("Soldier");
soldier.setPosition(1);
}
This will result in creating just 4 objects and configure them 1000 times with their position.
Facade is an exterior view/face of a building. We can understand the whole structure of the building by its exterior view.
But internally, they have lot of rooms, wiring, plumbing, interior decorations,etc., which we may not interested to know.
Day to day we deal with complex business functionalities. We seperate our business requirements into different classes and maintain the inter-operability between them.
We should be able to re-use such components within our application or from an external application whenever there is a need.
Our component may have a complex design with many business processings but we need to provide a simpler interface for other systems to use it. Such type of an interface is a Facade.
A railway reservation system is a complex process involving hundreds of rules or policies while booking a ticket. They have seperate systems to handle the list of stations,trains,quotas,preferences,etc.
We may not have much interest over the internal happenings of the system. We will end up in providing the details about the passenger and the seat preference.
The system will perform the complex processing and generate the ticket for us based on the data provided.
The following class diagram explains the Facade pattern,
Here, the Ticket class offers a simple method bookTicket() which is the facade for the complex ticket reservation process.
A single call to the bookTicket() will communicate with different systems like stations, preferences, ticket classes, quotas, etc., and generates the ticket for the passenger.
Refer the following code snippet for more details,
// Constructor
public Ticket() {
stations=new Stations();
train=new Train();
quota=new Quota();
preference=new Preference();
}
// Facade for booking the ticket
public void bookTicket(){
ticket.setClass(train.getTravelClass());
ticket.setFromStation(stations.getFrom());
ticket.setToStation(stations.getTo());
ticket.setPreference(preference.getPreference());
ticket.setQuota(quota.getQuota());
ticket.generate();
}
If we want to add new behaviors to our object during runtime, we can choose Decorator Pattern. In this pattern, we define a class and some set of behaviors applicable to the class separately.
We can patch up the behaviors to the class dynamically with out altering the class implementation.
In other words, the object can be decorated dynamically with various behaviors as per the need. Here,both the decorator and the object to be decorated belong, to the same abstract type.
Consider an example of creating a rainbow. By default, rainbow is having a single color as its behavior. We can add or remove colors to/from the rainbow dynamically.Hence, the rainbow object can be constructed and the colors can be added/removed on the fly.
Rainbow is an implementation of the abstract type Colors. We implement separate decorators for each and every color so that both rainbow and all other decorators belong to the same type, Colors.
Following class diagram will explain the concept in detail,
Here, we can add any new decorator or repeat the existing decorator without altering the Rainbow code.
Based on the above diagram the following code snippet shows the decorator pattern in action,
Colors rainbow = new Rainbow();
rainbow = new IndigoDecorator(rainbow); //Decorator 1 (Indigo)
rainbow = new VioletDecorator(rainbow); // Decorator 2 (Indigo)
Similarly, we can add dynamic behaviors to the rainbow object as,
rainbow=new AnyColorDecorator(rainbow); //Decorator N (Any Color)
we can also, decorate the rainbow class with the same color, repeated for any number of times.
In the Java API, InputStreams, Readers,etc are having decorator implementations.
