Interpreter Design Pattern

Download the working example demo code in java from my GIT repository –
https://github.com/premaseem/designPatterns/tree/master/ZipDownloadableProjects

Example Code Description :
1. Date interpreter example : The main cause of Y2K virus was interpretaiton of date format, in this example code I tried to address the same so that system can intrepret any date given in any formats. we have a interpreter for DD, MM and YYYY (rule to pick the date from context) so you provide the format and system gives you the conversion. Straight forward. 
2. And Or Expression : This example taks a string where in it should match the expression based on rule which accomplies And / Or expression. Code is simple and small but a bit triky to get hold of. Feel free to downlaod and play with it.

Direct link :
https://drive.google.com/file/d/0B-9WtmpPhI4ZREEwNWpRYWVzSGM/view?usp=sharing

Intent

• Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
• Map a domain to a language, the language to a grammar, and the grammar to a hierarchical object-oriented design.

Problem Area

This interpreter design pattern does not give solution for building a whole large interpreter for a language. It can be applicable for smaller chunks where grammar and interpretation is applicable. We can consider scenarios like regular expressions and interpreting mathematical expression.

Discussion

The Interpreter pattern discusses: defining a domain language (i.e. problem characterization) as a simple language grammar, representing domain rules as language sentences, and interpreting these sentences to solve the problem. The pattern uses a class to represent each grammar rule. And since grammars are usually hierarchical in structure, an inheritance hierarchy of rule classes maps nicely.

 

An abstract base class specifies the method interpret(). Each concrete subclass implements interpret() by accepting (as an argument) the current state of the language stream, and adding its contribution to the problem solving process.

Example

The Intepreter pattern defines a grammatical representation for a language and an interpreter to interpret the grammar. Musicians are examples of Interpreters. The pitch of a sound and its duration can be represented in musical notation on a staff. This notation provides the language of music. Musicians playing the music from the score are able to reproduce the original pitch and duration of each sound represented.

Check list

1. Decide if a “little language” offers a justifiable return on investment.
2. Define a grammar for the language.
3. Map each production in the grammar to a class.
4. Organize the suite of classes into the structure of the Composite pattern.
5. Define an interpret(Context) method in the Composite hierarchy.
6. The Context object encapsulates the current state of the input and output as the former is parsed and the latter is accumulated. It is manipulated by each grammar class as the “interpreting” process transforms the input into the output.

Advertisements

Memento Design Pattern

Download the working example demo code in java from my GIT repository –
https://github.com/premaseem/designPatterns/tree/master/ZipDownloadableProjects

Example Code Description :
1. Video Game Example : You can pick your player name, its mask and other details. You earn few more points and get the option to save the games state. Later you can restore your games state as well. The memento is used basically which clones your domain object and keeps it with itself. Care taker is the class which interects with client and talks to Originator. Originator component detals with domain object to save and restore the momento. Download, run and enjoy the game 🙂

Direct link :
https://drive.google.com/file/d/0B-9WtmpPhI4ZLV9rcFlmOXN2N0U/view?usp=sharing

Intent

• Without violating encapsulation, capture and externalize an object’s internal state so that the object can be returned to this state later.
• A magic cookie that encapsulates a “check point” capability.
• Promote undo or rollback to full object status.

Problem

Need to restore an object back to its previous state (e.g. “undo” or “rollback” operations).

Discussion

The client requests a Memento from the source object when it needs to checkpoint the source object’s state. The source object initializes the Memento with a characterization of its state. The client is the “care-taker” of the Memento, but only the source object can store and retrieve information from the Memento (the Memento is “opaque” to the client and all other objects). If the client subsequently needs to “rollback” the source object’s state, it hands the Memento back to the source object for reinstatement.

An unlimited “undo” and “redo” capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

 

The Memento design pattern defines three distinct roles:

1. Originator – the object that knows how to save itself.
2. Caretaker – the object that knows why and when the Originator needs to save and restore itself.
3. Memento – the lock box that is written and read by the Originator, and shepherded by the Caretaker.

Check list

1. Identify the roles of “caretaker” and “originator”.
2. Create a Memento class and declare the originator a friend.
3. Caretaker knows when to “check point” the originator.
4. Originator creates a Memento and copies its state to that Memento.
5. Caretaker holds on to (but cannot peek into) the Memento.
6. Caretaker knows when to “roll back” the originator.
7. Originator reinstates itself using the saved state in the Memento.

Rules of thumb

• Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
• Command can use Memento to maintain the state required for an undo operation.
• Memento is often used in conjunction with Iterator. An Iterator can use a Memento to capture the state of an iteration. The Iterator stores the Memento internally.

Mediator Design Pattern

Download the working example demo code in java from my GIT repository –https://github.com/premaseem/designPatterns/tree/master/ZipDownloadableProjects

Example Code Description :
1. Air Traffic Controller at air port : Flights classes have the behaviour of landing. Before landing they need to communicate to figure out if run ways is not blocker. With the same intent I have introduced a mediator class called at  ATCMediator.java which will mediate the communication between the flights and assist them for landing.
2. Producer Consumer for messages: Producer and Consumer (multiple objects) relies on a mediator for coordination of exact state to proceed ahead. This is a multi treaded program with intermediatory class – Mediator.java
3. Traffic Light Signal : When one light turns On, rest other have to be turned off. If each light will communicate with another lights to changes their state then it would be highly coupled and difficult to maintain. By introducing Light Mediator which is responsible to hold object reference of all other light and communication task, the design becomes flexible and decoupled. We can add any color light and remove it when ever we want that too at run time.  

Zipped code download link : https://drive.google.com/file/d/0B-9WtmpPhI4ZaU9rMnRIMjBTWFE/view?usp=sharing

Discussion :

Mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program’s running behavior.

Usually a program is made up of a large number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes.

With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

Before Mediator Design Pattern

So what is the problem we are trying to solve here? This complex interaction between objects creates dependency and tighter coupling. We stand for loose coupling, we want to reduce dependency as much as possible, we want more reuse.

After Mediator Design Pattern

Define an object that acts as a mediator between communicating objects thus removing the direct dependency between those communicating objects. This mediator object encapsulates the interaction information and uses it to enable communication between the objects.

The intermediate mediator object is not only to communicate between two objects, but it helps in interaction for a set of peer objects. This mediator object is like a router in networks, which is routes / controls or coordinates communication between systems.

Real-time Example for Mediator Design Pattern

Air traffic controller (ATC) is a mediator between flights. It helps in communication between flights and co-oridates/controls landing, take-off. Two flights need not interact directly and there is no dependency between them. This dependency is solved by the mediator ATC. If ATC is not there all the flights have to interact with one another and managing the show will be very difficult and things may go wrong.

Mediator Pattern Implementation

In a mediator design pattern implementation we will have

• mediator interface – an interface that defines the communication rules between objects
• concrete mediator – a mediator object which will enables communication between participating objects
• colleague – objects communicating with each other through mediator object

Check list

1. Identify a collection of interacting objects that would benefit from mutual decoupling.
2. Encapsulate those interactions in the abstraction of a new class.
3. Create an instance of that new class and rework all “peer” objects to interact with the Mediator only.
4. Balance the principle of decoupling with the principle of distributing responsibility evenly.
5. Be careful not to create a “controller” or “god” object.

Chain of Responsibility Design Pattern

Download the working example demo code in java from my GIT repository –https://github.com/premaseem/designPatterns/tree/4bb9beca7bab5b5e71d02b76e4f1ad48fce4aca6/ZipDownloadableProjects

Example Code Description :
1. Number Handler : Client passes a request (signed number ) to first node of change. Positive number handler will see if number is positive it will print it else pass it to next handler which is Zero number handlers, which in return do the same and pass it to negative number handler.
2. ATM Money dispatcher : Client would enter the amount ex $576/- to first node which might have different handlers for each denomination like 500 dollar bill handler, 100, 50, 10, 5, 2 and 1 dollar bill handers and finally dispatch the money. 
3. Log Handler : Client would enter a message and set the logging level based on which all the consoles would get notifications. In this example the chain is set, however the first node / handler is decided dynamically based on the log level (to skip unused nodes in the chain)

Download example code in zipped format : https://drive.google.com/file/d/0B-9WtmpPhI4ZYVNIc2hOcE5PSkU/edit?usp=sharing

Intent

• Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
• Launch-and-leave requests with a single processing pipeline that contains many possible handlers.
• An object-oriented linked list with recursive traversal.

Highlights of Chain of Responsibility

• Sender will not know which object in the chain will serve its request.
• Every node in chain will have the responsibility to decide, if they can serve the request.
• If node decides to forward the request, it should be capable of choosing the next node and forward it.
• There is a possibility where none of the node may serve the request.

Problem

There is a potentially variable number of “handler” or “processing element” or “node” objects, and a stream of requests that must be handled. Need to efficiently process the requests without hard-wiring handler relationships and precedence, or request-to-handler mappings.

Discussion

Encapsulate the processing elements inside a “pipeline” abstraction; and have clients “launch and leave” their requests at the entrance to the pipeline.

The pattern chains the receiving objects together, and then passes any request messages from object to object until it reaches an object capable of handling the message. The number and type of handler objects isn’t known a priori, they can be configured dynamically. The chaining mechanism uses recursive composition to allow an unlimited number of handlers to be linked.

Chain of Responsibility simplifies object interconnections. Instead of senders and receivers maintaining references to all candidate receivers, each sender keeps a single reference to the head of the chain, and each receiver keeps a single reference to its immediate successor in the chain.

Make sure there exists a “safety net” to “catch” any requests which go unhandled.

Do not use Chain of Responsibility when each request is only handled by one handler, or, when the client object knows which service object should handle the request.

Structure

The derived classes know how to satisfy Client requests. If the “current” object is not available or sufficient, then it delegates to the base class, which delegates to the “next” object, and the circle of life continues.

Multiple handlers could contribute to the handling of each request. The request can be passed down the entire length of the chain, with the last link being careful not to delegate to a “null next”.

Example

The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. ATM use the Chain of Responsibility in money giving mechanism.

Check list

1. The base class maintains a “next” pointer.
2. Each derived class implements its contribution for handling the request.
3. If the request needs to be “passed on”, then the derived class “calls back” to the base class, which delegates to the “next” pointer.
4. The client (or some third party) creates and links the chain (which may include a link from the last node to the root node).
5. The client “launches and leaves” each request with the root of the chain.
6. Recursive delegation produces the illusion of magic.

Rules of thumb

• Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers.
• Chain of Responsibility can use Command to represent requests as objects.
• Chain of Responsibility is often applied in conjunction with Composite. There, a component’s parent can act as its successor.

Visitor Design Pattern

Download the working example demo code in java from my GIT repository -https://github.com/premaseem/designPatterns/tree/4bb9beca7bab5b5e71d02b76e4f1ad48fce4aca6/ZipDownloadableProjects

Example code description : This is an interesting example which includes a Party. So the Party class has music, drinks and food. For the preparation Party Host class accepts visitor cooks  (Veg cook and Non-Veg cook). So the combination could be of a week end party / a week day party in which you can have veg / non veg cooked food. Please download and run the program once. Without using  pattern if we put logic in “if else conditions” them it could had been messy and maintaining it could had been a night mare.Visitor patter is blessing in disguise of use cases like these.

Intent

• Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
• The classic technique for recovering lost type information.
• Do the right thing based on the type of two objects.
• Double dispatch

Problem

Many distinct and unrelated operations need to be performed on node objects in a heterogeneous aggregate structure. You want to avoid “polluting” the node classes with these operations. And, you don’t want to have to query the type of each node and cast the pointer to the correct type before performing the desired operation.

public class Feeder {     public void feed(Dog d) {         d.eat();     }     public void feed(Cat c) {         c.eat();     } }   Feeder feeder = new Feeder(); Object o = new Dog(); feeder.feed(o); // Cannot compile!

This issue is called double dispatch as it requires calling a method based on both instance and parameter types, which Java doesn’t handle natively. In order to make it compile, the following code is required:

if (o instanceof Dog) {     feeder.feed((Dog) o); } else if (o instanceof Cat) {     feeder.feed((Cat) o); } else {     throw new RuntimeException(“Invalid type”); }

 

This gets even more complex with more overloaded methods available – and exponentially so with more parameters. In maintenance phase, adding more overloaded methods requires reading the whole if stuff and updating it. Multiple parameters are implemented through embedded ifs, which is even worse regarding maintainability. The Visitor pattern is an elegant way to achieve the same, with no ifs, at the expense of a single method on the Animal class.

public interface Animal {     void eat();     void void accept(Visitor v); }   public class Cat {     public void eat() { … }     public void accept(Visitor v) {         v.visit(this);     } }   public class Dog {     public void eat() { … }     public accept(Visitor v) {         v.visit(this);     } }   public class FeederVisitor {     public void visit(Cat c) {         new Feeder().feed(c);     }     public void visit(Dog d) {         new Feeder().feed(d);     } }

Discussion

Visitor’s primary purpose is to abstract functionality that can be applied to an aggregate hierarchy of “element” objects. The approach encourages designing lightweight Element classes – because processing functionality is removed from their list of responsibilities. New functionality can easily be added to the original inheritance hierarchy by creating a new Visitor subclass.

The Visitor pattern makes adding new operations (or utilities) easy – simply add a new Visitor derived class. But, if the subclasses in the aggregate node hierarchy are not stable, keeping the Visitor subclasses in sync requires a prohibitive amount of effort.

An acknowledged objection to the Visitor pattern is that is represents a regression to functional decomposition – separate the algorithms from the data structures. While this is a legitimate interpretation, perhaps a better perspective/rationale is the goal of promoting non-traditional behavior to full object status.

Let us take an example of Taxi. You (Person – domain object ) wants to visit a new a place in city. Now you do not want to implement the driving logic in your domain object. So you can add accept visitor method object in which the Taxi object might contain and execute the logic for you .

 

Check list

1. Confirm that the current hierarchy (known as the Element hierarchy) will be fairly stable and that the public interface of these classes is sufficient for the access the Visitor classes will require. If these conditions are not met, then the Visitor pattern is not a good match.
2. Create a Visitor base class with a visit(ElementXxx) method for each Element derived type.
3. Add an accept(Visitor) method to the Element hierarchy. The implementation in each Element derived class is always the same – accept( Visitor v ) { v.visit( this ); }. Because of cyclic dependencies, the declaration of the Element and Visitor classes will need to be interleaved.
4. The Element hierarchy is coupled only to the Visitor base class, but the Visitor hierarchy is coupled to each Element derived class. If the stability of the Element hierarchy is low, and the stability of the Visitor hierarchy is high; consider swapping the ‘roles’ of the two hierarchies.
5. Create a Visitor derived class for each “operation” to be performed on Element objects.visit() implementations will rely on the Element’s public interface.
6. The client creates Visitor objects and passes each to Element objects by calling accept().

Rules of thumb

• The Visitor pattern is like a more powerful Command pattern because the visitor may initiate whatever is appropriate for the kind of object it encounters.
• The Visitor pattern is the classic technique for recovering lost type information without resorting to dynamic casts.

Visitor Vs Strategy

The strategy pattern is like a 1:many relationship. When there is one type of object and I want to apply multiple operations to it, I use the strategy pattern. I think of the visitor pattern as a many:many relationship.
A Visitor is like an extended Strategy that is polymorphic at two dimensions: the code executed doesn’t only depend on the actual strategy used, but also on the parameter passed to it.
Strategy, State, Command, Visitor (and more I’m sure) all have some behavior built into an object that we can pass around, so they all have a very similar feeling when you’re building the object. Their “intent” is subtly different and yet sometimes overlapping.
Visitor is often (but not always) a way to add new functionality to an existing object graph. The example I learned on is an HTML parser that builds a DOM of objects on an HTML page and invites me to add functionality via visitors.

Template Method Design Pattern

Download the working example demo code in java from my GIT repository –https://github.com/premaseem/designPatterns/tree/4bb9beca7bab5b5e71d02b76e4f1ad48fce4aca6/ZipDownloadableProjects

Example Code Briefings : Template Method Fruit Juice extraction example defines a recipe (with exact steps and quantity) to prepare the drink which is kept in the extract class. However the flavor of the fruit Juice can be changed by it subclasses by overriding (which is defined as hooks/abstractor in parent abstract class).

Intent:
Define the skeleton of an algorithm in an operation, deferring some steps to client subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
Base class declares algorithm ‘placeholders’, and derived classes implement the placeholders.

Problem:
Two different components have significant similarities, but demonstrate no reuse of common interface or implementation. If a change common to both components becomes necessary, duplicate effort must be expended.

Definition:
Template method design pattern is to define an algorithm as skeleton of operations and leave the details to be implemented by the child classes. The overall structure and sequence of the algorithm is preserved by the parent class.
The component designer decides which steps of an algorithm are invariant (or standard), and which are variant (or customizable). The invariant steps are implemented in an abstract base class, while the variant steps are either given a default implementation, or no implementation at all. The variant steps represent “hooks”, or “placeholders”, that can, or must, be supplied by the component’s client in a concrete derived class.

The component designer mandates the required steps of an algorithm, and the ordering of the steps, but allows the component client to extend or replace some number of these steps.

Template Method is used prominently in frameworks. Each framework implements the invariant pieces of a domain’s architecture, and defines “placeholders” for all necessary or interesting client customization options. In so doing, the framework becomes the “center of the universe”, and the client customizations are simply “the third rock from the sun”. This inverted control structure has been affectionately labelled “the Hollywood principle” – “don’t call us, we’ll call you”.

Structure:
Template Method scheme
The implementation of template_method() is: call step_one(), call step_two(), and call step_three(). step_two() is a “hook” method – a placeholder. It is declared in the base class, and then defined in derived classes. Frameworks (large scale reuse infrastructures) use Template Method a lot. All reusable code is defined in the framework’s base classes, and then clients of the framework are free to define customizations by creating derived classes as needed.

Example:
Daily routine of a worker.

Rules of thumb:
Strategy is like Template Method except in its granularity.
Template Method uses inheritance to vary part of an algorithm. Strategy uses delegation to vary the entire algorithm.
Strategy modifies the logic of individual objects. Template Method modifies the logic of an entire class.
Factory Method is a specialization of Template Method.

Iterator Design Pattern

Download the working example demo code in java from my GIT repository –https://github.com/premaseem/designPatterns/blob/4f171f69bbeb34e614a6ed6d6e68df342e18d90c/ZipDownloadableProjects/IteratorPatternEmployeeExample.zip

To see code visit diff link:https://github.com/premaseem/designPatterns/commit/af9228704b70742e13f4264558ddf4e59f2b0073

Intent
Explicitly separate the notion of “algorithm” from that of “data structure”.
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
The key idea is to take the responsibility for access and traversal out of the aggregate object and put it into an Iterator object that defines a standard traversal protocol.

Problem solved by pattern
Need to “abstract” the traversal of wildly different data structures so that algorithms can be defined that are capable of interfacing with each transparently.

“An aggregate object such as a list should give you a way to access its elements without exposing its internal structure. Moreover, you might want to traverse the list in different ways, depending on what you need to accomplish. But you probably don’t want to bloat the List interface with operations for different traversals, even if you could anticipate the ones you’ll require. You might also need to have more than one traversal pending on the same list.” And, providing a uniform interface for traversing many types of aggregate objects (i.e. polymorphic iteration) might be valuable.

The Iterator pattern lets you do all this. The key idea is to take the responsibility for access and traversal out of the aggregate object and put it into an Iterator object that defines a standard traversal protocol.

The Iterator abstraction is fundamental to an emerging technology called “generic programming”. This strategy seeks to explicitly separate the notion of “algorithm” from that of “data structure”. The motivation is to: promote component-based development, boost productivity, and reduce configuration management.

Key Notes on Iterator in Java:
Iterator in Java basically is used to support generics thereby making it mandatory to make use of the Generic version of Iterator and not the Iterator with raw type.
In case the objects need to be removed from the Collection, in that case do not make use of for-each loop. Instead one can make use of Iterator’s remove() method to avoid any ConcurrentModificationException.
As far as Iterating over collection with the help of Iterator concerned, it is subject to ConcurrentModificationException if Collection is modified after Iteration started. However this is meant to take place only in case of fail-fast Iterators.
We have fail-fast and fail-safe type of Iterators in Java and you need to check for the difference between these types.
List collection type is also known to supports ListIterator that comprises of add() method so as to incorporate elements in collection at the time of iteration. Difference between Iterator and ListIterator has also been discussed above.

External vs Internal Iterator
When the client controls the iteration sequence and index position then it is called as the external iterator. Otherwise if the iterator controls the traversal then it is called internal iterator. On external iterator, the design is that the invoking client code should explicitly invoke the method to move the pointer to next element. For internal iterator, when an element is accessed, after access the pointer will be automatically moved to next index by the iterator. In general internal iterators are easier to use than the external iterators.