Sadaphule - Creational Design Patterns in Java

Preface

I have been working as software engineer professional in a multinational firm for more than 20 years. I feel its time to leverage my learnings over the years and mentor programmers on practices of writing reliable, maintainable and extensible software. I have learned lot of good coding practices the hard way by making mistakes first and learning from them along the way. Design patterns have helped me tremendously to avoid repeating those mistakes. This book documents commonly used creational design patterns and attempts to provide guidelines on how to avoid common pitfalls on software development by using right design patterns.

A Mckinsy study of 5,400 large scale IT projects (projects with initial budgets greater than $15M) in 2012 reported that 17 percent of large IT projects go so badly that they can threaten the very existence of the company. It also mentioned that on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. A lot of these problems can be attributed to bad code that becomes unmaintainable as code size grows. The Pareto principle indicates that 80 percent of outcomes can be attributed to 20 percent of the possible causes of a given event. Also known as the 80-20 rule, it's relevant to almost every field of human endeavor. The principle also applies to software engineering by saying that most problems are caused by a small number of bad coding practices. These practices can be eliminated by using design patterns thereby helping engineers and companies become more productive and successful.

Design patterns offer proven solutions to commonly recurring problems. When you see a common recurring problem, you find a common, general solution to solve it. It happens in architecture, mechanics, usability, and human behavior, and programming makes no exception. These solutions have been tried successfully in the past. This book attempts to bring awareness of these successful patterns among developer community.

I was impressed by Gang of Fours design patterns early on. I have used design patterns in large projects and was astounded by the amount of reusability the code offers when it makes use of right design pattern. Having knowledge design patterns creates a high level of maturity. Armed with knowledge, developer can look at bigger picture and thinks about extensibility and reusability before jumping into doing. Design patterns also happens to be one of favorite topics among interviews for software engineer. Hence having design pattern knowledge will give you an edge. It will take you to journey of becoming ninja developer.

This book covers creational design patters, Creation pattern enables programmer to build solutions to writing code that creates object(s) in fashion that keeps code extensible, maintainable and reusable.

Introduction

Design Patterns provide easy to recognize and use OOP solutions to common problems. They're inherently easy to maintain, because many people are familiar with them. This is very similar to how google works. Everyone knows HOW to google, so when you get a query like "What is the purpose of design patterns", you can very quickly use this common interface to solve a problem.

Design pattern can greatly increase efficiency, reliability and productivity of developer team as whole as it offers proven and tested solutions.

Creational design patterns are all about various ways in which class can be instantiated. The instantiation method varies based on what and how much of it developer want to control from consumer of code. This pattern is classified int class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done. This gives your program more control in deciding which objects need to be instantiated for a specified use case.

In Java, the way to create an object is to use new operator.

Foo = new Foo() ; // Instance of Foo class

Let us say its you who has written Foo class and gave the library to someone to use it. As you can see, the user of this library can instantiate any number of Foo classes with absolutely no control. Also here we are hard coding the way object is getting instantiated. In many cases, exact object that needs to be created depends on runtime behavior. Creation design patterns abstract the way object can be created. It can make program more flexible and generic.

• Factory Method
  It provides a class that decides what object need to be instantiated from a family of classes that are derived from common abstract class based on input data provides.
• Abstract Factory
  It provides ability to create instance of several families of classes
• Builder
  It provides ability to differentiate object construction from its representation. Hence depending on the need , various representations can be created.
• Prototype
  It provides lightweight method of creating new objects by cloning or copying existing instances.
• Singleton
  It provides ability to control number of instances that can be created by restricting it to one instance.

Background

Factory design patterns are useful in scenario where there is need to create instance of a class from related family of classes. For instance say there is a factory that makes electronic toys. All electronic toys share some common characteristic like they have a play and stop button. If you need a teddy bear, all you need to tell to factory is Hey make me teddy bear and the factory will make one for you and give it back to you.

If you need a tiger, you need to tell to factory is Hey make me a tiger and the factory will make tiger and give it back to you. In this case the user just passes in description of toy and let factory create the toy for user. The use can press play and stop button on the toy after purchasing the toy. Same factory can create other electronic toys like lion, dog etc. based on user need.

Implementation

Usually all of the classes have parent class and common functions. But each function operates on task differently. In addition there is a factory class that handles responsibility of understanding what class user needs, instantiating the required class and returning that instance. In the electronics toy factory example, all toys have common function called play, and each toy plays differently. When a teddy bear is asked play, it may sing a song. When tiger is asked to play, it may emit roaring sound. This relationship is explained in picture below.

Here IElectronicToy is an interface with two functions namely play and stop. It represents a contract that each electronic toy should implement. The contract is dictate by two methods play() and stop(). TeddyBear and Lion are two classes that implements IElectronicToy interface. By overriding play() and stop() methods. TeddyBear and Lion each have different implementation of play() and stop() methods. ToyFactory is a class with just one static method CreateToy(..). This method accepts ToyType enum and returns either TeddyBear or lion depending upon ToyType value casted as IEletronicToy. Client represents a external class that calls ToyFactory classs static method createToy and passes appropriate value of ToyType. It in turn gets a object of type IElectronicToy which internally could be reprinting TeddyBear or Lion.

Here is java code that implements above classes.

File : IElectronic.java