Tuesday, January 24, 2012

I am back again with a different pattern today. The name of the pattern that we are going to look at today is Command pattern. Usually this pattern is very famous as well as sometimes it makes us confused as well, anyway let's try to look at an analogy of this pattern in real life.

Back then in the world , there were wars between nations for something valuable , sometimes they waged wars on acquiring a piece of land or for some other resource. Whatever the reason we know that a war is not pleasant , but for the sake of understanding the pattern let's assume that two parties were in a war and this happened during the times that they had only swords and horses as weapons and transportation.

During these times if some party had wanted to send a command to it's ally about what should have been the next action, the leader of the group would have written the command in a piece of paper ,possibly would have encrypted in a certain way and would have sent this through a trustworthy person.

Once this command had reached the ally the message would have been received by the leader of the ally and he would have ordered his warriors to act according to the command. In this case there was no need for the two leaders to know each other personally and they did not directly communicate to each other either. Also the first leader could have sent more than one message written in more than one papers. In such case the person who had been delivering the message to the other ally had had the privilege of passing the messages in a certain order , possibly following the instructions from the first leader.

Now it is a good time for us to look at command pattern in detail to have a better understanding on how the example and the pattern go together. Command pattern may be used in situations like explained above. If you need to decouple a sender and a receiver and encapsulate command related logic elsewhere , Command pattern is a good choice. Also this help in delayed or timed execution of a particular command as well as queuing the commands based on a certain set of rules.

In Command pattern , there are few actors involved ,

1. Sender
2. Receiver
3. Invoker
4. Command itself

If we take above analogy , the Sender would be the leader of the party , Receiver would be the leader of the ally, Invoker would be the warriors who were going to act , and the Command itself is the message written in the piece of paper. In this case we see that the Sender and the Receiver is decoupled and also the Sender could send more than one piece of paper containing completely different command as well. In such case Warriors would act on each command according to it's assigned priority. That means Command pattern would also help you queue more than one command and execute based on some sequence.

//Command sent using a paper to the ally
public class MoveToEast implements Command{
public void execute(Warriors warriors){
warriors.moveToEast();
}
}

//A main method to see all actors in action
public static void main(String args[]){

//The leader of the party is initiating the command to Ally
PartyLeader leaderOfTheParty = new PartyLeader();
leaderOfTheParty.initiateCommand();
//This is as if the leader of the party writes the command in a piece of
//paper and sending it via a messenger
Command commandToAlly = leaderOfTheParty.getCommandToAlly();

//now that the leader of the Ally
AllyLeader leaderOfTheAlly = new AllyLeader();
//Leader of the ally receives the command from the messenger and probably reads it
leaderOfTheAlly.receiveCommandFromParty(commandToAlly);
//Then the leader of the Ally instructs his warriors what should be done
leaderOfTheAlly.commandWarriors();
}

It is clear that the Sender (PartyLeader) does not have any idea about the Receiver (AllyLeader) , neither sender knows who is going to execute the command. And the Receiver does not know about the Sender , but knows what to do with the command. The actual work is done by the Invoker , (i.e Warriors in this case). By using a Command Sender and Receiver are decoupled well.

Note: Command pattern sometimes confuses us , if you have questions you may place a comment for which I could help answering...:)

Thursday, January 19, 2012

Have you ever attempted to book a cab ? If yes then today's lesson is going to be easy for you. For the people who have not ever done that , I am going to give a crash course :). Well if you need to book a cab you just need to call the cab service provider's number and talk to the representative at the other end.

When you inform the representative about the pick up point and the destination he or she will do the coordination and pass this information to a cab which is nearer to your location. In this case you talked to the representative not to the cab driver. And the cab driver also talked to the representative , not to you directly. In short representative is becoming a medium for you to transfer the message that "you need a cab" , and the representative transfers a message to cab driver saying that "there is a passenger waiting for".

Imagine that if you ever had to book a cab by directly calling a cab driver, it would have been extremely difficult and chaotic. On the other hand you would have to know about all the numbers of cab drivers whom you could probably contact. But surely , we know that this is not going to work easy for us and we will be wasting time trying to get hold of a cab. Instead you get a representative who has all the information about the cab drivers such as contact numbers , current location etc.

Well that is the real life example , but how can we apply this in the field of software ? . Imagine for a moment that you have two or more applications which need to send messages among each other , possibly to do some application processing. Let's say the systems are SystemA , SystemB and SystemC. If these systems send messages to each other , it would be like,

1. From SystemA to SystemB
2. From SystemB to SystemA
3. From SystemB to SystemC
4. From SystemC to SystemB
5. From SystemC to SystemA
6. From SystemA to SystemC

If System A , System B , System C communicates as mentioned above , those will surely be making a spaghetti when communications are considered among them. It is chaotic , it is difficult to maintain and would waste lot of time and energy.

Now that , lets say we are going to introduce some other entity as a middleman among these systems and mandate those system to communicate to the middleman at the same time mandating the middleman to communicate to the systems whenever it is needed. Once this arrangement is in place , the middle man becomes a focal point. System A , System B and System C communicate to middleman as a client and middleman would communicate to any system which is acting as a receiver according to the request from a client.

In this case , systems do not communicate to each other directly , instead a mediator is used. The mediator would know to which system to send the messages received from the client. This set up will surely make it easy to maintain , would help specializing roles of the systems and would surely save some time and effort as well.

That is what we call as Mediator pattern , it is quite simple. Let's do some coding then....
public abstract class System{
private MiddleMan middleMan;
public void registerMiddleman(MiddleMan middleMan){
this.middleMan = middleMan
}
public void sendExternalSystemMessage(String message , System system){
middleMan.recordMessageFor(message,system);
}
public void receiveExternalMessage(String message , System receivedFrom){
//do something with the message from another system
}
}

System systemA = new SystemA();
System systemB = new SystemB();
System systemC = new SystemC();

MiddleMan middleMan = new MiddleMan();

//register middle man with each system,
//this is as if all the cab drivers know the representative
systemA.registerMiddleman(middleMan);
systemB.registerMiddleman(middleMan);
systemC.registerMiddleman(middleMan);

//register systems with middleman, this is as if representative knows
//the all the cab drivers
middleMan.registerSystem(systemA);
middleMan.registerSystem(systemB);
middleMan.registerSystem(systemC);

//send messages from systems to systems
systemA.sendExternalSystemMessage("this is from A to B",systemB);
systemB.sendExternalSystemMessage("this is from B to C",systemC);
......

Monday, January 9, 2012

Here I am back again , to give you some insight into another GOF pattern , namely Observer pattern. Let's take a simple example to understand this pattern.

Nowadays phones are very common and many people are using those.We also know that two of most important functionalities of a phone is that making or receiving calls , and sending or receiving of short messages (SMS). Lets focus on receiving calls and receiving SMS(s). Also let's assume that a member of your family has gone to a competition and rest of the family is awaiting the result at home and it is about the time that he or she should either call you or send an SMS letting you know the result.

Now that in this case all the family members are paying great deal of attention to the phone and are expecting to have some form of communication from the other person. In case if the rings all the family members would try to quickly pick the phone up and receive the call , or else if a text is received all the members are eager to quickly pick up the phone and read the message. In other worlds all the family members are sort of observing the phone until a call or an sms is received. Now that I have mentioned the word "Observe" and you must have been hinted about the pattern a bit.

Let's look at the example in the context of the Observer pattern. In this case the family members are paying lot of attention to the phone observing it and waiting for a call or an SMS , in other words all the family members are observers now. If a call or sms is received they will be very quick and will respond to that by answering or reading the content. On the other hand we could call the phone as an object of which the family members are interested in. Also the state of the object would make them to react accordingly. Also the object would notify the observers, in this case by a ringing tone. In essence this is what you should try to achieve in Observer pattern. The pattern is used in situation where a group of things must be notified based on the events which happen in the other. In addition to that the group of things which must be notified would be registered with the subject so that subject can notify them when something important occurs in the subject itself.

In the above analogy the subject is the phone and the family members are the observers. And the attention that is paid by the family members are like observers getting registered themselves with the subject. Also the ringing of the phone can be seen as the notification by the subject to its registered observers.

Let's have a look at how we could do this with some code....
//subject
public class Phone{
private List<FamilyMember> observers = new ArrayList<FamilyMember>();

This is basically what we call as an implementation of Observer pattern , the observers are registered with the subject and the subject would notify all the registered observers when an event occurs in the subject it self about which observers are interested in getting notified. Lets put this into our analogy, the family members are interested in receiving a call or a text to the phone and they are paying a great deal of attention to the phone , when the phone receives an SMS or a call it will notify all the family members by ringing itself.