Design Patterns - Creational Patterns

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:

1. Design patterns describes the communication between objects
2. They are recurring solutions to recurring problems, thus enabling reuse of solutions to common problems
   

Design patterns are divided into three categories, viz.,

1. Creational Patterns: Cover the cases for object creation
   
2. Structural Patterns: Compose groups of objects into larger structures
3. 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.

1. Acceptance: You accept that it is an important part of your work. I'm past this point and that's why I'm here! ;-)
2. Recognition: This is the learning stage where you begin to recognise the patterns, both the problem and solution patterns
3. 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:

1. 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.
   
2. 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 Pattern
From 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 Pattern
The 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

Summary
To summarise this blog entry, I've gone through the first section of the book and looked at the creational design patterns, viz.,

1. Factory
2. Abstract Factory
3. Builder
4. Singleton
5. 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!

Savio's Notes: Java Book: Effective Java - Chapter 2 - Item 1

The first in a series of notes about the book Effective Java by Joshua Bloch will cover Chapter 2 - Item 1. Some sharp readers would be wondering why not Chapter 1. Those who have read the book will be aware that Chapter 1 is more of an introduction to the book and it also will explain why I didn't make any notes for it. So worry not, you haven't missed anything yet!

Item 1
Use static factories instead of constructors
I never thought of it in these terms, but I had always felt uneasy whenever I used the new operator in code. I always tried to never to use the new operator and have either a third utility class that returned a newly minted instance or have a static method that did the same.

But Joshua Bloch puts it more eloquently and convincingly and here are his reasons:

1. Static factories unlike constructors can have more meaningful names which in turn help code readability
2. Static factories unlike constuctors do need to create a new object every time. They could implement some kind of caching mechanism to enable reuse of instances
   
3. Static factories unlike constuctors can return sub-types of their return types

The book also lists disadvantages of this item as:

1. Classes without public or protected constructors cannot be sub-classed. But he goes on to state that this may be an advantage as it forces the use of composition over inheritance which is further elaborated in Item 14
2. Besides the use of naming conventions there is no way to distinguish a static factory from other static methods in the class

In conclusion the book recommends using static factories unless you are convinced that it dooesn't suit your needs. Alternatively if you are confused go with constructors as they are the norm.

From my part, I will now be trying this pattern more often to put in private constructors and use static factories. Maybe the convention to use would be to have the static factory name as getInstanceUsingXxxx(...)

Savio's Notes: An introduction to a blogging series

I recently got my hands on a copy of Effective Java - Programming Language Guide by Joshua Bloch. I've been meaning to read this book for quite a while now as I've heard nothing but praise from most people I know who have read it. Also, having read Effective C and absolutely loving that book, I'm a little biased because of the title of this book.

So I began reading it and got through the first three chapters and thought to my self: "Hey this is common sense stuff and still there are some common mistakes pointed out too!"

It's always great when someone else (a more famous person than oneself) confirms what one is thinking. Now I'm not trying to say that I've known everything that I've read so far. Quite the contrary I've also learnt a quite a bit of new stuff. Which is exactly why, given my terrible memory I though I should make notes for the same.

Now had I been in the office, I'd have Wiki-ed this. So rather than that, I thought let's start a kind-of series on my blog called Savio's Notes that will track these notes of mine on this and various topics.

As the title of the series suggests, the series is not one that is polished and proper. It is an aid to a quick reference and a summary of sorts of the things I'd like to remember.

I'll use the following convention for the title of the post when I create one that belongs to the series: Savio's Notes: Sub-series: Post title

With that introduction I'll now move to the first post in the series, viz., Savio's Notes: Java Book: Effective Java - Chapter 2 - Item 1 to Item 6