I finally began a long overdue task of upgrading my design skills by reading the book
Design Java. During this process I'll start another series to summarise my readings.
The book is based on another well know book by the Gang of Four but with a focus on implementing the original 23 design patterns in Java. Very rightly, it starts by highlighting the importance of design patterns today as:
- Design patterns describes the communication between objects
- They are recurring solutions to recurring problems, thus enabling reuse of solutions to common problems
Design patterns are divided into three categories, viz.,
- Creational Patterns: Cover the cases for object creation
- Structural Patterns: Compose groups of objects into larger structures
- Behavioural Patterns: Defines communication and data flow between objects in a system
Another thing I liked is the way the book highlights the learning pattern for design patterns.
- Acceptance: You accept that it is an important part of your work. I'm past this point and that's why I'm here! ;-)
- Recognition: This is the learning stage where you begin to recognise the patterns, both the problem and solution patterns
- Internalization: This is where you apply your knowledge.
These three steps aren't specific to the learning of design patterns but in fact are the general steps to learn anything and everything. It's an internalised process but knowing the explicit steps helps in understanding the process.
Two things to remember when using any design patterns are:
- Program to an interface and not an implementation: This principle is the at core for reducing dependence on an implementation. Programming to an interface allows implementation to change with time for any reasons, e.g., better algorithms, newer technologies, newer frameworks, etc.
- Favour Composition over inheritance: While this is not what we are taught in the OO theory, in reality favouring composition over inheritance eases up decoupling many a time. When I was first told this by one of my previous team leads (Irfan Mohammed), I thought he did not know what he was talking about! However, now I'm older (and hopefully wiser) and have realised the wisdom in his words then. I now go on preaching the same thing to everyone I meet!
Creational Patterns:
Creational Patterns are used when we need to handle special cases while creating new objects. The simplest way to create objects in Java is to use the
new operator. However, many a time, special cases need to be considered and Creational Patterns may be used to solve them.
These are the five Creational patterns.
Factory Pattern
Creates different implementations for an abstract class or interface based on the input parameter(s). The client is unaware of the implementation being returned. If the implementation is changed, only the factory needs to be changed and the remaining part of the client is not affected.From a previous post, I've also highlighted the benefits of using a static factory instead of calling the constructor directly. This is a variation on the Factory Pattern and I'd like to re-iterate to use the
new operator only inside a Factory.
Abstract Factory Method
The Factory pattern applied to the Factory! Creates different factories that in turn provide different implementations for an abstract class or interface based on the input parameters.
Singleton Pattern
The Singleton Pattern is probably the most well know pattern. It's aim is to create a single object for a given class. There are a number of ways to do this in Java of which I favour the following:
- Creating a static implementation
Use a private constructor to prevent object creation.
The methods and data within the class are static
This pattern doesn't create a single instance and can still fulfill the requirement of having a single point within the system.
The downside to this is that the object is not dynamic, meaning it cannot be passed around nor can it implement any interfaces. It is best suited for utility classes.
- Factory that ensures only a single instance is returned
This has two flavours. An external factory or an internal static factory method. In both cases the factory ensures that an object instance is created only if one doesn't exist or returning the already created instance.
I favour the factory pattern over using static implementations because it is a bit more flexible and reduces the static coupling that the first method mandates. The additional benefit of the latter is that it can easily be extended to provide a pool of objects or to remove the singleton requirement if found necessary later.
Builder PatternFrom what I understand, the builder pattern and the factory pattern are different parts of the same coin.
The
Factory or
Director is used to create the
Builder objects.
When the factory creates instances that are more complex in nature and which in turn
build different implementations even though the interface implemented is the same. In terms of a UI, the builder is responsible for constructing different views or different UI to represent similar data in different representation based on a slight difference in the data. The book gives an example of using the
Builder Pattern to create multi-select list of items a group of checkboxes if the number of items are three or less or a multi-select listbox if there are more than three items. The
Factory decides which builder is to be created based on the data sent to it.
Prototype PatternThe
Prototype Pattern is largely used to create copies of an object. This is useful when the object creation is expensive. For example a database lookup or network call is required to populate and create an object. However, the same data in the object may be required to be manipulated or represented in different ways. Again an example from the book is of creating the
prototype object after a database file lookup. Then creating a copy of the data a sorted list.
The book also talks about the default Java method for creating object copies, i.e., the
clone method, and rightly highlights the common pitfalls of the clone method. IMO, the first rule for the clone, method is
don't use it! But there are times you can't avoid it, and one has to be extremely careful in implementing an override.
Secondly, just overriding the clone method results in a
shallow copy, i.e., all mutable referenced objects are common to both the prototype and the clone. If this is not desired and one needs a
deep-clone Java does not really help you and you have to implement it yourself. Up until I read this book, this meant going through the complete object graph and recursively calling clone on every referenced object. But, the book highlight a simple cheat, use serialisation! It's so neat and elegant. Use a
ByteArray to serialise the prototype using the
ObjectOutputStream and then deserialise the object to create a
deep-clone using the
ObjectInputStream. Simple! Neat! Few lines of code! But it does have it downside, viz., every object in the graph must be
Serializable.
The caveats for the prototype pattern is mainly it's impact on performance. While creating the copies of the prototype relatively cheaper than creating instances of the prototypes, there still is an expense of doing a deep- pr shallow-copy. Every instance retrieved of the prototype is always a copy which in turn will have a hit on performance.
My 2 paise here, especially in cases where read-only information is required, it would make sense to return an immutable interface to the object or an immutable clone if possible. But then this is a creational pattern and the reason one would use it is to create mutable instances of objects that are expensive to create from scratch. But I couldn't resist documenting my thoughts... (after all it is my Blog...uh... Blikki) :-D
SummaryTo summarise this blog entry, I've gone through the first section of the book and looked at the creational design patterns, viz.,
- Factory
- Abstract Factory
- Builder
- Singleton
- Prototype
Of these I think Factory is the basis for all creational patterns and the rest are really subtle extensions of it. And this is how I'll remember them:
Factory creates objects. If the objects created are factories in their own right then the top factroy is an
Abstract Factory.If the objects construct something like UI etc., then the objects are
Builders. A
Singleton is a
Factory returning only one instance of the object while a
Prototype would be one that creates copies of an object.
Five creational patterns all linked with the core pattern
The Factory!
