Creational Patterns:

Creational Patterns are the design patterns which are used for constructing the objects. Below are the different types of Creational Patterns:

1. Singleton Pattern.
2. Prototype Pattern.
3. Builder Pattern.
4. Factory Pattern.
5. Factory Method Pattern
6. Abstract Factory Pattern.
7. ObjectPool Pattern.

Singleton Pattern:

The name of the pattern represents the instance of the class should be one only instance and it should be instantiable. For example, in a system there should be only one Calendar instance. Usually singletons are used for centralized management of internal or external resources and they provide a global point of access to themselves. Below are few points to be considered.
- Should have private constructor.
- Should be self instantiable.
- Should be one instance.
- Should have a utility method which returns the same instance of the Singleton object.

It involves only one class which is responsible to instantiate itself, to make sure it creates not more than one instance at the same time it provides a global point of access to that instance. In this case the same instance can be used from everywhere, being impossible to invoke directly the constructor each time.

The implementation involves a static member in the "Singleton" class, a private constructor and a static public method that returns a reference to the static member.


eg:
class Calendar {

private Calendar calendar;

private Calendar() {

}

public Calendar getInstance() {
if(calendar ==null) {
calendar = new Calendar();
}

return calendar;
}
...........
}

Typically whenever we access Calendar, we will get the same object.

Difference between FactoryMethod/Builder Patterns:
The Factory Method is also a Creational Pattern, but is classified as a Class Creational pattern, where the Builder Pattern is an Object Creational pattern. The difference in classification is that "Class" Creational patterns deal with the relationships between the parent class and subclasses.Inheritance plays a big role in these patterns. Object Creational patterns deal with the relationship between objects and is usually created during runtime.

The Builder pattern is the creation of objects step by step. The Factory Method pattern defines an interface and let the subclasses decide which object to instantiate.

Design Patters for OOPs

Why we need perfect design?

Designing OOPs software is hard and designing resuable software is even harder. We need to figure out realtime objects factor them into the classes at right granularity, define classes, interface and inheritance relationships among these objects. Our design should be specific to the be problem we are trying to solve but also general enough to solve the future problems because of the future changing requirements. Irrespective of programming language every OOP programmer require the design skills.

Software Design Principles:
Software design principles represents a set of guidelines that helps us to avoid having a bad design. Below are the software design principles:

Open Closed Principle:

Software entities like classes, interfaces are open for extension but should be closed for modification. Meaning if any existing classes/interfaces can be extend/inherited for modifications by overriding (Polymorphically). But the existing classes/interfaces should be closed for modificaiton. eg: Any frameworks released in major/minor versions eg: Spring/Struts/Hibernate etc..

Dependency Injection/Inversion Principle:
Consider class/modules depends on some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. Typically in software engineering pratices "Lossely coupled, tightly cohesion" between the Objects. In order to decouple them the first module will get the reference from a property/XML file, basically the same was called IOC in Spring which is core package of Spring framework and an external module controlling the dependencies will inject the reference to the second one.

Interface Segregation Principle:
Interface should define the methods which are required specific to that module. Eg: Vehicle is a interface :

interface Vehicle {
Model getModel();
SpeakerSystem getSpeakerSystem();
Engine getEngine();

}

class Bicycle implements Vehicle {

// Bicycle might have Model , Engine but not SpeakerSystem.
public Model getModel(){
.....
return model;
}
public SpeakerSystem getSpeakerSystem() {
return null;
//Here speaker system is null which means speaker system not applicable
}
public Engine getEngine() {
//Most of the advanced Models of Bicycle have some kind of engine/motors.
return engine;
}

}

Interfaces containing methods that are not specific to it are called polluted or fat interfaces. Such interfaces definition should be avoided.

Click here to know the list of the Category Patterns.