Iterator Design Pattern

Iterator design pattern provides us a way to access the elements in a collection sequentially without exposing internal implementation/representation details to the client.

Programming languages provide a wide variety of collections/aggregates for storing the objects. List, Set, Arrays, Maps etc are very commonly used aggregates used by programmers. We employ different  aggregates for different scenarios and use-cases. But traversing through these aggregates always remains a requirement and is a very basic need in any kind of software program.

As these basic aggregate classes vary in underlying data structures, hence ways of traversing them also varies. We can naively provide methods in aggregates to access the elements, but this can easily expose internal details. Moreover, client code would also need to deal differently with different aggregates even though their need is same(accessing elements sequentially) and hence their are huge chances of code duplication.

Iterator pattern provides a solution to these basic aggregates traversing problems. We basically do two things when we implement iterator pattern.

First, we move the responsibility of traversing the aggregate elements to another class called Iterator. An iterator provides an interface for clients which they can use to traverse the elements. All iterator implementations thus provide this interface.

Second, we make aggregates to provide a simple interface to enable users to get hold of the iterator. Aggregates just need to instantiate appropriate iterator and provide it to client.

These simple structural changes mean several benefits. Aggregate is now only concerned about its core responsibility of storing the elements, while it is now Iterator's responsibility to traverse the elements in the aggregate. It greatly simplifies aggregate interface and also helps in achieving S of SOLID principles. Aggregate just provides interface which clients use to get hold of the iterator. Aggregate has now just two uniform interfaces to deal with irrespective the type of aggregate.

Code structure

Code structure is relatively simple.

Aggregate implements a simple interface which clients invoke to get Iterator instance. Aggregate just needs to instantiate appropriate concrete iterator implementation. Iterator provides clients the ways to traverse though the aggregate elements.

Java Iterators

Java collection classes implement Iterable interface. It maps to Aggregate in aobve UML diagram. This interface has three methods, one of which needs to be implemented by the concrete class(other two have default implementations). This method is named 'iterator' and it returns an Iterator.

Iterator is a simple interface having three basic methods for traversing collection elements:

• hasNext: returns true is iteration has more elements
• next: returns next element in iteration
• remove: removes last element visited

remove has also a default implementation of throwing UnsupportedOperationException. So if a collection class doesn't want to support this method and hence doesn't implement it, exception is thrown to let client know about it.

There are several concrete implementations of Iterator available, like ListIterator. Concrete collection classes instantiates appropriate iterator implementations and return it as implementation of 'iterator' method.

Template Method Design Pattern

Template Method Pattern is a behavioral pattern. It basically involves defining a method called Template method which defines steps/skeleton of an algorithm and hence controls the overall execution of the algorithm. These individual steps are either implemented in same class or declared abstract so that sub-classes can provide suitable implementation. Template method is made final so that sub-classes can't temper with the structure of the algorithm.

Template method design pattern is heavily employed in development of frameworks. This design pattern helps a lot in avoiding code duplication. Also, algorithm is implemented at a single place and hence it is mush easier to make any changes. This gives much better control over any future modifications.

Code structure

Code setup consists of an abstract class and concrete classes extending the abstract class. Abstract class contains skeleton of the algorithm expressed in terms of a sequence of method calls with each method corresponding to a step in algorithm execution. Some of these methods may be implemented in abstract class and are final so that sub-classes can't change them. Other methods are declared abstract and sub-classes their implementation as per their needs. Template method too is declared final so that sub-classes can't change skeleton of the algorithm.

Some hook methods can also be provided. These are concrete methods but are either empty or provide default implementation. Sub-classes can override them if they want to. Hook methods are heavily used in frameworks, for example as life-cycle methods of various frameworks.

The Hollywood Principle and Template Method

The Hollywood Principle helps to avoid dependency rot in a software system. It basically means that low level components hook into a system but its high level components which decide when and how are low level components are needed. It is popularly phrased as "Don't call us, we will call you".

Template method design pattern also exhibits similar behavior. Parent class controls the flow of the algorithm and invokes sub-class methods whenever needed. Clients interact with parent class abstraction rather than a sub-class implementation. Sub-classes' role is just to provide specific implementations of the steps in algorithm while flow control is determined by parent class only.

Facade Pattern

Facade pattern is a structural pattern. Like Adapter pattern, it also alters an interface but with the purpose of simplifying it.

Many times we have to work with a complex software system which consists of various parts. These individual parts have their interfaces for clients to work with. We need to use system as a whole to get some work done and this work is done by interacting with different individual parts of the system. Interacting with so many subparts and hence so many interfaces makes our task quite complex and involves many steps.

We can make use of Facade pattern in such situations to simplify interaction with a complex system. We design a simple interface, called as Facade, for client to work with, and Facade internally interacts with different parts of the complex system. So now all the complex implementation of interacting with various interfaces of the complex system is within the Facade and client just needs to interact with this simple interface. Facade doesn't restrict access to low level functionalities of the system and client can still access low level classes if needed. 

Code structure

To implement a Facade, we design a class which is composed of different subparts of the complex system we plan to provide simple interface for. This class is our Facade for that complex system.

Facade is composed of different subparts of the complex system needed to get some work done. Client just interacts with Facade.

Facade pattern is also a way to implement OO design principle of least knowledge(also known as Law of Demeter) in a system. This principle seeks to reduce number of classes an object interacts with as much as possible so that our system is less fragile and less complex to understand. With Facade pattern, client now only interacts with Facade instead of all those subparts in the complex system.

Adapter Pattern

Adapter pattern is a structural pattern. It enables us to make classes work together which otherwise can't because of incompatible interfaces.

Suppose we have an existing software, and we are making use of a third party library to get some work done. Library has an interface exposed to work with it, and hence we have designed our software to be compatible with this interface. But down the line, there is a new library available and it performs better than our current library. So we decide to replace older one with this new super library.  But there is hurdle. New library exposes an interface which is different from interface we have designed our software to. We don't want to change our existing design, and of-course we can't change new library's interface.

Adapter pattern comes to our rescue. It enables us to design a class which sits between our software and new library and acts as a mediator and adapts the new library interface into what our software expects. This mediator class is called Adapter. It basically receives requests from a client and transform them into requests which a receiver can understand.

Code structure

Adapter pattern enables us to encapsulate the changes which we need to do when ever interface we need to work with undergoes a change. This decouples client code from the interface changes, and its the adapter class which undergoes that change and hence client doesn't need to be modified whenever client needs to work against a different interface.

Client only knows of interface it is designed to work with. We call it Target. Adapter class implements Target. It is composed of Adaptee which has the interface Client is not compatible with. but it has the action that Client wants to perform. So Client invokes request on Adapter which delegates the request to Adaptee.

If Adaptee changes, changes we need to make are only in Adapter and hence Client is decoupled from Adaptee.

Adapter pattern is heavy with good OO design principles. Client is bind to an interface, rather than an implementation. Also, Adapter uses composition to wrap the Adaptee. Moreover, we can now use Adapter with subclasses of Adaptee.

Object and class adapter

In Adapter pattern discussion so far we have wrapped Adaptee object inside an Adapter. This is object based approach and it uses composition. We can also have a class based approach wherein Adapter subclasses an Adaptee class. So in class based approach, we use inheritance instead of composition. This reduces flexibility as object based approach enables us to work with subclasses of Adaptee. But in class based approach we can override Adaptee's behaviour.

Example

Older types of Java collections like Vector and Stack provides Enumeration interface to work with these collections. Enumeration has methods to step through the collection, like hasMorElements, nextElement().Later Java versions introduced Iterator interface to iterate step through the new types of Collections, like List. 

If we want to make use of Iterator interface in our code, but are still working with legacy code which exposes Enumeration interface, we can make use of Adapter pattern.

Our code becomes Client, Iterator becomes Target interface, Enumeration class becomes Adaptee. We need to design Adapter class to make our code work with Iterator while underneath Adapter interacts with Enumeration. Two methods in Enumeration directly maps to Iterator methods(hasNext(), next()), but Enumeration doesn't have any method which corresponds to remove() in Iterator. So we make a compromise here, and throw UnsupportedOperationException in our implementation of remove() in Adapter class.

What we may not like

As requests are delegated, so there is an overhead.

Command Pattern

Command pattern is a behavioral pattern. This pattern allows us to encapsulate a request(receiver, methods, arguments) inside an object, and thus client code can be made free of specific implementations of receiver types, thus decoupling the code.

Suppose we have a class with a method, say performAction(). This method receives an object as argument and has a basic responsibility of interacting with object. Object belongs to a group of objects. These objects get some work done, but unfortunately they don't have a common interface. Instead they have different set of methods to be invoked from performAction(). A very naive implementation of performAction() can be like:

In this implementation, client code is strongly coupled with specific implementation types rather than interface and hence it reduces code flexibility. If there are new types of objects in the system in future for with to deal with, this code would undergo change. This violates 'O' of 'SOLID' principles, and is a source of possible bugs.

Command pattern enables us to get rid of such code implementation and instead we encapsulate requests in objects we call as Command and client code then parametrize invoker(performAction()) with a Command object. We can now dynamically set the Command object, making performAction() interact with different types of object without having this sort of strongly coupled code.

Basically, when we want to decouple an object from making requests to objects which actually perform those requests, we use Command pattern.

Code structure

Command is an interface which has a single method, execute(). Client creates ConcreteCommand which is a specific implementation of Command, and sets Receiver in it. Receiver is the object which contains the actual actions. Invoker has a method setCommand() which Client uses to set Command. It also contains method performAction() which Client calls later on as needed. It is this method which invokes execute() on Command object.

ConcreteCommand basically represents the encapsulation of the request, as it contains the Receiver object and in its execute() it invokes all the required methods of Receiver needed to compete the command.

We can have different concrete Command implementations containing same type of Receiver. They would differ in their invocation of methods on Receiver.

Making use of Command pattern ensures that conditional code from invoker method is no more there and that logic is now expressed in form of different concrete command implementations.

Another way of looking at Command pattern is that it allows us to package a computation(receiver object and actions on it) in an object and pass it around as first class object. Hence, we can invoke computations away from its original point of creation, both in terms of time and space. For example, we can create it in one thread, move it around and then invoke it in another thread. This idea can be applied to many useful use cases like schedulers, thread pools, job queues.

For example, we can implement a queue to which we can add Command objects at one end, and on other end Threads can remove those objects one by one and call execute() method on them. Queue implementation in itself is totally decoupled from the computation aspects. It just acts as a conduit. Thread object just needs to invoke execute() on receiver and it has no other coupling with it. So as long as objects added to queue implement Command interface, we can be sure that execute() method would be invoked on them whenever a Thread is available to remove them from the queue.

Undoing

If our use case is to also support undoing what execute did, then we can add undo() method to Command interface, and in concrete implementation we can then call appropriate method on receiver object in undo().

Example

Runnable interface is a perfect example of Command pattern. Runnable interface corresponds to Command interface in UML diagram above. It has method run() which maps to execute(). We provide concrete implementation for Runnable which corresponds to ConcreteCommand in diagram.



Client code instantiates the concrete Runnable and handover it to a Thread which becomes the Invoker. Client can either set a Receiver explicitly in concrete Runnable or we can have the logic embedded inside run() itself. Thread's start method maps to performAction() in UML diagram above.

What we may not like

If there are many commands in the application, it would lead to too many command classes, and naturally more maintenance efforts.

Factory Method Pattern

Factory Method Pattern is a creational pattern.

In a framework, we generally have classes representing abstractions and framework needs to manage relationships between objects of these classes, and also creation of these objects. Clients extend these abstract classes for specific implementations. Problem here is that framework only knows abstract classes and not their concrete implementations.

Factory Method Pattern provides a solution to this problem. This pattern allows us to define an interface to create an object, but lets subclasses decide how to implement the interface, thus deferring instantiation to subclasses.
It encapsulates the knowledge of which specific implementations needs to be instantiated and moves this knowledge out of the framework.

Factory Method approach

An abstract method is defined in the abstract creator class. This method is supposed to have the responsibility of creating instances of appropriate product classes. Subclasses of abstract creator class then implement this method to implement creation of  instances of specific products.

We use Factory Method pattern when:

• A class don't know about specific implementations it need to instantiate
• A class wants its subclasses to decide which type of objects to be instantiated

Code structure

Code structure we need to implement Factory Method pattern is as follows:

We define an abstract class Creator which contains an abstract factory method. This factory method has contract of returning an instance of type Product, which is another abstract class.

In subclass of  Creator, like CreaotrA and CreatorB, we implement the factory method. Specific implementation creates instance of specific implementation of Product, like ProductA or ProductB.

Consequence of this code structure is that client code(like 'someOperation' method in Creator) is decoupled from concrete implementations of Product as well as creation logic, and it has to deal only with Product interface. Subclasses of Creator are in full control of which type of Product to create without client code being impacted if there are any changes in creation logic.

Basically what we achieve here is to separate object creation logic from the code which uses that object. So down the line object creation knowledge may undergo a change but client code is decoupled from this change. This makes client code adhere to 'O' of SOLID principles.

Also, factory method pattern is one of the way we can implement 'D' of SOLID principles. As now high level component('someOperation' in Creator) does not depend on low level component(different implementations of Product), instead both now depend on abstraction(Product), and thus it introduces 'Dependency Inversion' in our code.

We can have factory method parametrized. This means that method would take an input parameter and use it to decide which product to create. It's a good practice to use enums as parameters to make sure that parameters are type safe.

Parallel class hierarchies

Another way of looking at it is that we encapsulate creation knowledge of a certain type of products into their respective creator. This helps in maintaining parallel class hierarchies. For example, in above UML diagram CreatorA is responsible for creating instances of ProductA, while CreatorB is reposnsible for creating instances of ProductB. Both creators are subclasses of Creator while both products are subclasses of Product. So we have two parallel class hierarchies evolving here and factory method is the connection between them.

What we may not like about Factory Method?

If a new type of Product has to be instantiated and existing Creator implementations are not a good fit to create it, then we may have to create a new Creator subclass for it. This is a bit of overhead just to instantiate a new type of Product.

Decorator pattern

Decorator pattern falls under category of structural patterns. Purpose of Decorator pattern is to enable us to add additional features to an object dynamically at run time.

Why not subclassing?

One may argue to make use of subclassing an existing class to add additional features/functionalities to our class, and hence to its objects. This is in fact a well practiced approach, but it has some disadvantages apart from strong coupling between parent and child class.

First, parent class behaviour is added to all objects of the child class which may not be desired. Second, a behavior inherited from a parent class is locked into child class at compile time, and hence we can't influence the time at which we actually want object to have a particular behaviour.

Another major disadvantage can be that if there is scope for a large number of combinations of these behaviours in our system and we make classes for all possible combinations, then it may lead to class explosion, leading to huge maintenance problem.

Decorator pattern

Decorator pattern enables us to add additional features/responsibilities to the objects at run time in a very flexible manner. We can decide which behaviour to be added, when to be added, how to be added.

Decorator approach

Target object which we want to have a specific feature is wrapped inside another object having that feature. Enclosing object is called decorator, and importantly it has same interface as target object so that client code can invoke same interface. When client sends a request, decorator object forwards that request to target object and additionally add its own action(decoration) before or after it. Multiple decorators can be applied recursively, hence allowing to add as many features as we want.

We define the interface of the target object/class. And we define an abstract Decorator class which implements this interface, so now it has same interface as target object and client can invoke calls on it transparently.This abstract class also contains the reference to target object. We implement concrete classes for Decorator,wherein we direct client requests to target object.And while it does so,it also performs the 'decoration'.

Please keep in mind that all class based inheritance done here is just to make sure that a common interface is maintained across all objects involved in the process. Hence, we don't suffer from the disadvantages we discussed above in context of subclassing.

Code structure

Lets look into code structure we need to have to implement Decorator pattern.

UML diagram is as follows:

First, we have a class to define a common interface to be used by clients transparently:

We implement functionality in a class:

Our aim is to add additional features to objects of  SimpleComponent at run time.

So we define an abstract decorator class:

Now we add specific decorators:

Lets now put it all together and see how it works:

Running this program would give following output:

Core functionality implemented here

Decoration done by DecoratorB
Decoration done by DecoratorA

So, we are able to add behaviours to target object dynamically. If needed, we can add additional features as and when we want, thus handing lots of flexibility to our system.

Example

java.io package can be looked into to see working example of Decorator pattern.

InputStream is an abstract class and is super class for all classes representing an input stream of bytes. It has an abstract method read() which every subclass needs to implement. This class can be mapped to Component class in UML diagram above.

There are several concrete implementations of InputStream, like FileInputStream which reads bytes from a file in the file system. FileInputStream can be mapped to SimpleComponent in our UML diagram.

There is another class, FilterInputStream. This class extends InputStream and contains some other input stream, which it uses as basic source of bytes, and possibly transforms the data or provides additional functionality. It can be mapped to Decorator class in UML diagram.

Finally, there are classes which extend FilterInputStream, like BufferedInputStream. This class adds functionality of buffering the input data.

So, if we need to read data from a file one character at a time:

What we may not like about Decorator?

A quite obvious downside of Decorator pattern is that sometimes it leads to too many small classes in the system which makes it easy to understand and debug.