Web Technology

Did you ever encounter issues while designing systems where more than one component is interacting with other component. If yes, the most obvious issue which you might have encountered would be the coupling issue. That is making one component interact with the other yet not making them know about others functioning. Well, today the pattern we would be talking about revolves around this issue. We are talking about command pattern.

Let us first understand what is command pattern. The formal definition is "Command Pattern encapsulates a request as an object, thereby letting us parametrize clients with different requests, queue or log request."
To understand it better, let us say that we would like to design a scheduler, which reads a request from a queue and process each until the queue is not empty. And possible requests includes:
a) Order request holds data to be written in database if the request is for an order performed.
b) If request pertains to weather reporting tool, it requests a weather class to return current temperature from a data source and then finally writing the data to a remote socket.
c) If request pertains to a third party tool, it reads its DB and creates a connection to a remote server and writes the requested data.

And for performing such operation we already have specific request classes available.
As you can see each of these request is of very different type. And we would not like scheduler to practically verify the request type and then invoke each classes pertaining to the actual request. If we do so, we would be increasing the coupling between scheduler and the request classes.

This seems to be the classic case where we can apply command pattern. Let us jump into this then without wasting any more time.

Well let us see which all classes are available for above requests:

a) Order class which allows setting an Order ID and then making a call to UpdateDB() which updates the DB using the Order ID.

b) For weather reporting a class named WeatherManagement is available, which exposes methods to read data from a component and then finally sending the data to remote client.

c) For third party tool, a class named ThirdPartyToolManagement class is avaiable which allow reading data from DB and then posting the data to an address.

Well, as you have seen we do not want scheduler to directly use these classes, we are going to apply the pattern.

The steps to apply command pattern in our case are as follows:

1. All command object will require to apply a single standard so let us define an interface named Command with a method declared Execute()

2. The actual command needs to implement the interface so that pur scheduler can make call to a single method irrespective of command. The possible commands in our case are
a) OrderCommand

b)WeatherCommand

c)ThirdPartyCommand.

So each of these will require implementing the inteface we defined above.

So let us see one of these classes:

public class OrderCommand implements Command
{
 Order objOrder;  //this is reference to the class which was supplied for order management
 
 public OrderCommand(Order objOrd)
 {
  objOrder = objOrd;
 }

 public void Execute()
 {
  objOrder.UpdateDB();
 }
}

Similarly each of the other commands can be defined.

3. Allowing the scheduler to set the command. For this let us define our Scheduler class, using the one command we have seen for our complete understanding

public class Scheduler
{
 Command objCmd;

 public void SetCommand(Command objCommand)
 {
  objCmd = objCommand;
 }

 public void ExecuteScheduler()
 {
  objCmd.Execute();
 }
}

Let us put this to a trial run:

public class TrailScheduler
{
 public static void main(String args[])
 {
  Schduduler objScheduler = new Scheduler();

  Order objOrder = new Order(); //creating an instance of actual receiver

  objOrder.SetOrderID(12); //set the order Id on which operation is to take place

  OrderCommand objOrdCmd = new OrderCommand(objOrder); //creating a command and wrapping the order instance

  objScheduler.SetCommand(objOrdCmd);//setting the command finally in the scheduler

  objScheduler.ExecuteScheduler();
 }
}

This is explain the functioning, though in reality a Scheduler will be dynamic and will not be static as shown here.

But what we have just seen is a single command. In reality Scheduler will have to deal with multiple command. So the command instance will be an array of commands and scheduler will serially loop though them and execute the command. And in reallity a Scheduler will be a daemon process..so let us dress it up like that

public class Schedueler
{
 Command[] aObjCmd;
 
 public void Scheduler()
 {
  aObjCmd = new Command[10];
  Command nullCmd = new nullCommand();

  for(int i = 0; i < 10; i++)
  {
   aObjCmd[i] = nullCmd;
  }
 }

 private void RetrieveNSetCommand()
 {
  aObjCmd = GetDataFromSource(); //this retrieve the ready command objects from a source
 }

 public void ExecuteScheduler()
 {
  while(true) //make it infinite
  {
   RetrieveNSetCommand(); //this loads all command from a source

   for(int i = 0; i < 10; i++)
   {
    aObjCmd[i].Execute(); //execute each of the retrieved commands
   }
  }
 }
}

Refer to the class diagram below for details.



As you have seen we have decoupled the scheduler from the actual request it is making. Now our scheduler no more worry about the actual command it is processing. All it knows is it is required to make a call to Execute() method and that's all.

If you need any clarification, please write to me.

Labels: architecture, Command Pattern, coupling, decorator design pattern, decoupling, Object Oriented Patterns

Let us look into a pattern which will help us learn how to decorate our classes at runtime using a form of object composition. Yes, we will talk about Decorator Pattern today. It is influenced by the design principle which says "Classes should be open for extension, but closed for modification." That is, by applying this pattern our classes need not be modified for extension. Let us now jump into a real time example.

Let us say we got an offer to develop an object oriented system for a fastfood chain. The system has to calculate the price for each order that is placed at the counter. This system will be installed on the macros placed at the counter.
This may sound simple, but the issue is there are N number of combination for an order. For analyzing this requirement further let us track few of the orders to understand the combination.

Order No. 1: One Turkey Breast + without cheese + with dark chocolate toppings.
Order No. 2: One Oven Roasted Chicken Breast + with extra cheese + dark chocolate topping.
Order No. 3: One Black Forest Ham + with extra cheese + fruit cream topping.

If we see orders above, you would see that each order is different and each person could choose any one ham and any combination of toppings out of given list of toppings. The good thing is that we have a list of hams and a list of toppings.

Now can you think of an object oriented design to solve this?

Well, let us try solving this with our conventional inheritance patterns.

Solution 1: We could create one abstarct class named Burger with an abstract method named Price() and specific classes dedicated to various combination of orders possible. Each such order implementing its Price() method to calculate the price for the order. But, as you might have already realized it is not a clean solution. It has too many disadvantages like it leads to class explosion, next, each time a new ham or topping is added to the menu it leads to changing the combinations, which leads to rewriting code and biggest disadvantage is that when ever a price change for any one items, all methods will have to undergo modifications. Well, in all a bad design.

Solution 2: We continue to have this abstract class Burger with properties to identify toppings like extra cheese, chocolate topping etc. That is, attribute could be bIsCheese, bIsChocolate. And setter methods to set properties to identify the toppings. The Price method now is no more abstract. The Price method of Burger class calculates price based on properties set. And the concrete classes like TurkeyBreast or OvenRoastedChickenBreast overrides the Price() method of parent class (Burger). The Price() method calls parent Price to get the Price for toppings and then adds its specific Price for the Ham.
Again not a clean solution.
OK, now we are sure that such solutions, using inheritance is not a feasible solution. Let us try now applying object combination.

Solution 3: Applying Decorator Pattern:

Let us apply decorator pattern which allow building order with combination of various items at run time. Let us see what is decorator pattern first.
The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality.

Now let us apply this to our problem. To do this we will define an interface named Burger. This will be implemented by TurkeyBreastHam, OvenRoastedChickenBreastHam and BlackForestHam. The Price() method of each of these classes will return the Price of its own. This interface Burger, is also implemented by abstract class, which will be responsible for applying decoration to our class. This class is named ToppingsDecorator. It has an abstract method named Price(). The reason behind its implementing the interface Burger is to apply same type as that of the objects to be decorated. The decorator should of same type as that of the object being decorated.

Now each of out Toppings viz., DarkChocolate, Cheese and FruitCream will inherit the abstract class ToppingsDecorator. It has an reference to Burger as an attribute, which gets initialized by its constructor.

Let us see the class diagram:



The Price() method will have following definition:

return 0.30 + objBurger.Price();

i.e., it returns the addition of its own price and add Price of the Burger it decorates.

The complete class definition for some of the classes are as follows:

public class TurkeyBreastHam implements Burger
{
public double Price()
{
return 0.99;
}
}

public abstract class ToppingsDecorator implements Burger
{
public abstract double Price();
}

public class DarkChocolate extends ToppingsDecorator
{
Burger objBurger;

public DarkChocolate(Burger objBurg)
{
objBurger = objBurg;
}

public double Price()
{
return 0.30 + objBurger.Price();
}
}

Let us see one of the implementation to understand it better

public class FastFoodSystems
{
public static void main(String args[])
{
Burger objBurger = new TurkeyBreastHam(); //order a TurkeyBreastHam
objBurger = new Cheese(objBurger); // on this order a Cheese toppings
objBurger = new DarkChocolate(objBurger); /// and then a DarkChocolate Topping
System.out.println("The Total Price for the order is " + objBurger.Price()); //the price of order TurkeyBreastHam + Cheese + Dark Chocolate
}
}

So, this is our solution. It is clean and a scalable solution. We need not modify the class to add new items in menu, we simply add new classes.

That's all for the day. Do let me know what you feel about it.

Bye for now....

Labels: decorator design pattern, design, Object Oriented Design