import java.util.HashMap;
public class SessionFactory {

Exsisting Class Hierarchy

Here, we are hard-coding toppings of Pizza. Which are, in fact, individual Object in the real world. So in a way, they are Add-on objects that can be used to decorate our pizza. If we want to add new item as toppings, we need to modify the class. Ideally, we should be able to add any new topping “without modifying the class”, hence we come to know Open-closed principal.

“Classes should be closed for modification and open for enhancement.”

Now question is how to achieve this. Let’s note down what approach we need to follow to get maximum flexibility in design (maximum in terms of toppings and calculating its cost) in creating one FreshVeggiePizza with Paneer and Olives.
1. Take plain Pizza object.
2. Decorate it with Paneer.
3. Decorate it with Olives.
4. Call cost() method, which will be delegated to “Add-on” or “Decorator” objects also to add up their cost.

Here is the diagram that will clarify exactly how the cost will be calculated for this pizza.

Cost Of FreshVeggiePizza With Paneer & Olives

There is one important point in this diagram if you noticed. There has to be cost() method in each “Decorator” object as well as “FreshVeggiePizza”. So we will create one super class “Decorator” for each topping item. Food class will have cost() and getDescription() methods. In addition to that, we should be able to print description of the food according to what toppings are added, rather than tucking description into Pizza class.

Class Design With Decorator Pattern

Here is the example to realize this diagram.

public abstract class Food {
String description;
public String getDescription(){
return description;
}
public abstract void cost();
}
public abstract class Decorator extends Food {
public abstract String getDescription();
public abstract void cost();
}
public class FreshVeggiePizza extends Food {
public FreshVeggiePizza(){
description = “Fresh Veggie Pizza”;
}

public double cost(){
return 100;
}}
public class Paneer extends Decorator {
Food food;
public Paneer(Food food){
this.food = food;
}

public String getDescription(){
return food.getDescription + “, with Paneer”;
}

public double cost(){
return food.cost() + 15;
}
}

Let’s take a look at what happens in this code. Here our “Non-decorator” food will return description set in the constructor. So we have default implementation of getDescription() in Food class. We want to enforce each Decorator to implement getDescription() method in such a way so that it also reflects object it is decorating. So we have getDescription() method abstract in Decorator class. Now, Decorator classes like Paneer also needs to know which food it is decorating, so we need to pass the decorated food in the constructor of Paneer. In this way, we can create our other pizza and sandwich classes and their decorators.

Recipe Of FreshVeggiePizza with Paneer and Olive :

1.  Create classic FreshVeggiePizza.
Food pizza = new FreshVeggiePizza();
2. Put a layer of Paneer over it.
pizza= new Paneer(food);
3. Spread some olives over pizza.
pizza = new Olive(pizza);

Your FreshVeggiePizza with paneer and olives is ready. Now if you print price of the pizza, it will calculate cost for FreshVeggiePizza + cost of Paneer + cost of Olive. This is the fair level of dynamism that we can expect at this stage of Objectville.

Open-closed Principal Achieved:

We don’t need to change our Pizza class at all to add toppings on it that may change cost of the pizza. We don’t care if cost of paneer or olive booms, because we can parameterize those attributes and it is “decorated” over pizzas rather than tightly coupling it into pizza.

Decorators In Practice :

To take a look at real life decorators, have an eye over java.io classes. Replace Food with InputStream, Decorator with FilterInputStream, FreshVeggiePizza with FileInputStream/ByteArrayInputStream/StringBufferInputStream and Paneer with PushbackInputStream/BufferedInputStream/DataInputStream.

Summary:

Identify properties and methods common to decorators and client components (in our case, client is Pizza). Create super class for these common methods. Create Decorator super-class and identify methods which need to be implemented by each decorator. Pass reference of client in each decorator to allow decorator to add its own properties. Hence, job of decorator is to extend behavior of client and that too without modifying existing code.


public abstract class Food {
private List ingredients;
private String description;
public abstract double cost();
}


Pizza class will extend this Food class and add pizza specific property in this class. For example, crustType, extraCheese, olives, jalapano, paneer etc. If the pizza subclass needs to add jalapano in the toppings, value of jalapano will be true. Similarly, we can have Sandwich class, extending Foot class and adding some Sandwich specific properties to it. Then we can have subclasses like ItalianPizza, DoubleCheesePizza, FreshVeggiePizza subclasses that extend Pizza and will have implementation of cost() method(by overriding). By this approach, we no more need to create separate classes for ItalianPizza with olives, with Paneer etc. Here is the class diagram for this.

Revised Class-diagram

Let’s check out how it works. When we create instance of, say ItalianPizza, then we can set jalapano, olives true or false according to what we want in the toppings of the pizza. Using the same properties we can calculate cost of the Pizza.

It’s now time to check out what issues can arise in this approach.
1. What should we do if price of cheese goes up? Here, we are hard-coding price of cheese in cost() method.
2. What if some new item is introduced for toppings? For example, corn.
3. What if double cheese is required.

Oh god… save me now… Its not going any where near how we want it to be. Next time, we will eliminate these all the issue by introducing one well-known decorator pattern.

DoubleCheesePizza
ItalianPizza
FreshVeggiePizza
Vegetable Sandwich
Cheese Sandwich
Aalu-matar Sandwich

We also need to take care of our ordering system in hotel so we need one attribute called “cost” in all of the above classes. We will have descriptions of each item. Keeping in mind likings of customers, we need to have thin crust pizzas, as well as thick crust pizza. So lets have a look at these classes.

public class DoubleCheesePizza {
private List ingredients;
private String description;
private String crustType; // Thin crust or thick crust
private String size; // Small, Medium or Large

public doublecost() {
// Calculate Cost For DoubleCheesePizza
}
// Other getters and setters

}

Here we have ingredients for printing purpose and we have cost() method in each class, which will calculate cost of item based on its attributes e.g. crustType, size etc.

Similarly, we will have FreshVeggiePizza and ItalianPizza. But being in Gujarat, we need to remember Jains also so we will include one additional boolean attribute “withOnion”, so that we can have it true or false. We can also have provision to have grated cheese or liquid cheese. We will need a boolean for “liquidCheese”.

CheeseSandwich class can be like this:

public class CheeseSandwich {
private String name;
private String description;
private List ingredients;
private boolean withExtraCheese;

public double cost() {
// Calculate Cost For DoubleCheesePizza
}
// Other getters and setters
}
Remember, we need to add many more items in our menu as Objectville gets popular. So just imagine a scenario when Objectville will be among the most popular restaurants. Customers will definitely expect flexibilities like have some extra cheese in pizza, have some customized toppings like jalapano and olives in freshVeggie. Exclude capsicum from Italian pizza, have “grilled” vegetable sandwich, have some cheese on Aaloo-matar sandwich. And cost is going to vary according to toppings used. If we go with this same design, we will end up with something like this.

Class Explosion

So one problem we see clearly here is explosion of classes. We need to create a class for every customization in the item. May it be some single addition in topping or some different method in cooking. The other problem here is, our cost() method becomes tightly coupled. What will we do if price of cheese goes up.

This design really seems like stupid, when we are well equipped with power of inheritance, polymorphism & aggregation. This is kind of class design that we really don’t want. We will try to get rid of these issues next time.

Next>>

After thinking for quite a while for what to post in the blog, I thought its not bad to go in Kathy’s way. If you didn’t ever try then just have on eye on any book of Kathy Sierra or you can say synonym of Kathy is “Head First” books. Just google out any of the “Head First” book and you will surely get “never read before” books.

So I finally decided that I will open one restaurant Objectville soon. But to make Objectville rock in the town, we will be serving very few fastfood only in the initial stage, however, we want to go long way so we need system with strong architecture. But we don’t even want to increase complexity of the system unnecessarily by just piling up different patterns without thinking whether its needed. So I would like to start off will very simple, ‘anti-object-oriented’ kind of design, will check out the issues that arises and then recover. And don’t worry.. There are still few days to go in inauguration of Objectville restaurant so possible redesign won’t cost too much.

Here is the menu that we are going to offer initially.
1 Double -cheese Pizza – will have bunch of delicious liquid cheese on top of thick crust
2 Italian Pizza – will have Mozzarella cheese along with tomato sauce with sweet basils and oregano on top of crusty Italian bread
3 Fresh-veggie Pizza – brimming over with capsicum and crunchy onions.
4 Vegetable Sandwich – prepared and served fresh with crispy capsicum, fresh tomato and our
spicy green chutney in bread slices.
5 Cheese Sandwich – grated cheese stuffed inside breads with aroma of garlic in it
6 “Aalu-matar” Sandwich – typical Indian style piping hot sandwich stuffed with potatoes and peas cooked.

We will surely have classes of these items which we will see in the next post and will also think of what else we can offer initially to make Objectville rock. So next time, we will design “anti-object-oriented” classes for our restaurant. Remember, descriptions of these item will come into picture later. Discussion point of view, will try to be programming language independent as much as possible except the code snippets.

I appreciate your time to leave feedback and help me learn and improve Objectville.

When developing client tier of application using html,  there are certain limitations in using patterns because code is going to be in xml so while developing Swing/GWT/Desktop application’s GUI, we have support of Inheritance, Polymorphism and other constructs of language, so in this world, we can play around with patterns, so if we use patterns properly, reusability can make our life easier and it may get worst if not used properly.

HMVC(Hierarhcical Model View Controller) Introduced:

HMVC can be seen as extended version of MVC pattern. We can divide our GUI into different GUI objects some of which will be for navigation purpose (Menubar), some for displaying/editing data(Grid/Tree/Forms) and others may be use for just layouting purpose. So we clearly identify three major aspect of GUI objects.

1. Layouting – It is taken care by View in HMVC.
2. Handling user interactions – Its Controller‘s responsibility.
3. Server Interactions And Hold Data Being Displayed – Model handles this.

In HMVC, we assign dedicated Controller and Model for each of these objects. It is not necessary to provide each of the GUI object its own controller and model. To keep it simple, we can give dedicated controllers and models only to all the Pages, Grid, Dynamic Tree and other major navigation areas e.g. ContentPanel.

Getting In Depth Of H-M-V-C: In MVC architecture, View can only interact with Controller directly and  Controller can communicate with its associated model. Direct communication between View and Model is not possible. Hence View and Model will have references to Controller only and Controller will have access to associated Model and View. In addition to this, Controller will also have ParentController associated with it, which we will see in detail later. When we create new instance of View its associated Controller and Model should be instantiated, we will call this Model-View-Controller set as Triad. Inter-layer communication  is possible only through ApplicationEvents. AppEvent has its type and name. Event type can be NAVIGATION_EVENT, DATA_REQUEST_EVENT or REFRESH_VIEW. One thing to always keep in mind is each triad/controller knows and handles only those events that it is responsible for. For example, “Login” triad knows only how to log-in user.

NAVIGATION_EVENT: Navigation event is initiated from View, from where it is passed to controller. Controller checks whether it can handle the event or not. If not, then using chain of responsibility pattern is applied and event is passed through hierarchy of its parent controllers. And when the first controller which can handle the event is found, this hierarchy is stopped.

DATA_REQUEST_EVENT: Data Request Event is one which has server communication involved. This is init. from view, and after being delegated by controller its finally handled by Model which does client’ interaction. After response from server, model fires NAVIGATION or REFRESH_VIEW event to controller to show new page/ refresh data that was requested.

1. View: View has dedicated role for lay-outing the GUI, applying css classes to the components and fireEvents to the controllers when user interaction takes place. As stated earlier, we can divide screen into GUI objects and certain criterias to give it dedicated controller & model can be complexity in the object, amount of navigation inside the panel or amount of data that needs to be transferred with server and frequency of these transfers. Each view will have acces to its child panels. For example, consider diagram below which shows components of “ExamplePage”  in which page is divided into Header, Menubar, NavigationPanel, Preview panel etc. UI object that have dedicated controller and model are outlined in Red. We will name 3 triads in this page as pageTriad, contentTriad, innerNavigationTriad and repectively we can call controllers of  them as pageController, contentController and innerNavigationController.
   

   "ExamplePage" Components

2. Controller: Controller’s main responsibility is to delegate events to view/model/parent controller and synchronizing data between view and model. As discussed earlier, controller has associated parentController. For example, consider example above, in which case, parentController of “contentController” is set to “pageController”, parent of “innerNavigationController” is set to “contentController”. Here PageTriad can handle events fired from Menu bar only, ContentTriad can handle events fired from NavigationPanel and it can update preview panel accordingly, InnerNavigationTriad can handle updation in InnerPreviewPanel, however, if there is any event inside “InnerNavigationPanel” to update “PreviewPanel” outside InnerTriad, then chain of responsibility comes into play. InnerNavigationController can not handle this event, so it passes this event to parent controller – “AdminController” which can handle updation in “PreviewPanel”. Here is the diagram to understand hierarchy of triads and how they are associated.
   

   HMVC Layers

   When dataRequestEvent is fired from view, controller has fixed set to steps to do (1) Get data from view and set it to model and (2) Delegate event to model. As we know what we need to do, we can code this in the super-class of controller in following way.
public abstract class Controller{
View view;
Model model;
public void handleEvent(AppEvent event){
if(event.getType.equals("DATA_REQUEST_EVENT")){
setModelData();
model.handleEvent();
}
}
public abstract void setModelData();
public abstract void setViewData();
// getters and setters of view and model
}
Here, setModelData() will be abstract method in the super class of Controller. Our all other controller will extend this Controller class. For Example, lets see what if we want to create “Login” widget’s controller. Its setModelData() method would be somewhat like this.
public void setModelData(){
model.setUserName(view.getUserNameTF().getText());
model.setPassword(view.getPasswordTF().getText());
}
Similarly, we can write setViewData() method which will synch data of view with model.  After server response is received, model will fire REFRESH_VIEW event to controller and controller can call setViewData() to synch view and then call refreshView() method to actually update view in screen.

3. Model: Model is responsible to hold data that is displayed in view, communicate with server to get latest data and after server response, fire REFRESH_VIEW or NAVIGATION event on controller.

Here is the class diagram that may help to implement this pattern and identifying what interface each layer needs to provide to communicate with other layer.

HMVC - Class Diagram

Summarizing the pattern, complex UI objects are given dedicated controllers and model that communicate with each other through events. DataRequestEvent go from View->Controller->Model->Server->Model->Controller->refreshView() and Navigation events are handled by controller using chain of responsibility. When the first controller that can handle the event is found, chain ends.

After this initial framework is build, it becomes too easy to add new components later or debug existing component and we can also build super classes for each type of UI component for example Page, Grid or Tree. Will get into details of those in coming posts.

References:
Javaworld HMVC Tutorial
The Centric HMVC Tutorial

Suggetions and queries are always welcome. Email me at vishal1shukla2@gmail.com.