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.