Copyleft and Disclaimer for Tutorials

This is an attempt to document my experiences on technology, programming languages and operating system (on software in a much sensible/broader term). I offer this tutorial to those who are seeking the knowledge. I strongly believe in "Freedom" in the spirit of Open Source. While, I have taken efforts to verify the steps, methods and code, I cannot be held responsible for losses of any form. Please be aware that these tutorials come to you without any warranties. Until, I find a suitable Open Source license (more open for being open and less open for keeping it closed), the readers are advised not to modify. If you modify, you have host the modified and full version of the tutorial for free to all your readers. Bare minimum, maintain a copy of the modified tutorial via a website which is accessible publicly. Spread the goodness to the world like Open Source. We deserve Freedom and so is the entire world.

I would like to dedicate this work (and the series of works) to those teachers who constantly spread the knowledge to fellow beings generations to generations.

What is Creational Pattern?

As name suggests, the creational patterns are used in object creation. Any object oriented programming language will give you an infrastructure to create objects and perform whole lot of operations. One of the important and primary operations in any application is creating object. For example, in Java, you can create objects of any concrete types using "new" operator. However, the Java compiler or JVM do not know, are you creating objects in right way.  The way we choose to create objects decides many aspects such as reusability, maintainability and flexibility. Though we create objects in an application, we will creating objects for so many reasons. For instance, in the case of Singleton it enforces creating only one object for a class (type). As the purpose and scope of the objects vary, the way in which they are created should also vary to reap full benefits of Object Oriented Programming. There cannot be single solution for whole a lot of problems.

Let us consider a real world example. Assume that a car manufacture is planning to manufacture new brand (assume Swift by Maruti). While designing the car, the designers will focus on individual aspects of the car. There will also be a mechcanism to customize any model or to add features to the car. The extra fittings or specific model (Vxi, Zxi) will have its own assembling mechanisms. The dealers or the customers do not need to worry about how the car is made. They just give which model they want and the car is delivered to them. Internally, Maruti will have its own processes and standards to manufacture car hiding all the manufacturing details. It may choose to manufacture the parts or procure it from a different vendor. It is all internal Maruthi and the user does not need to know too much of details. It is all about exposing needed level of abstraction to the clients - not more and not less.

Also, as a developer, it does not make sense to fill your code with lot of "new" operator. By using "new" operator in lot of places makes the code to break maintainability and flexibility. When few more classes are added to the package or namespace, the developer will face a nightmare maintaining the code and quality of the code is also degrades.

So, the creational patterns helps to create objects in a better way rather than using "new" operator. When you use creational patterns (or any design pattern), you will be programming to an interface and not to the implementation. When you program to interface, your code becomes flexible and maintainable. In the next series of posts, we will be discussing creational patterns one-by-one.