core design principles

 MUST REMEMBER 4 ALL PROGRAMMERS 

– Encapsulate what varies

– Favor composition over inheritance

– Program to an interface, not implementations

– Strive for loosely coupled designs between objects that interact (Observer)

– Classes should be open for extension and closed for modification (Decorator)

– Dependency Inversion Principle: Depend on abstraction. Do not depend on concrete classes. This principle suggests that our high level components should not depend on low level components instead both should depend on abstractions. (Command Pattern)

– Principle of least knowledge: Only talk to your friends (Façade Pattern)

– Hollywood Principle: Don’t call us, we will call you. (Template, Factory Method, Observer Patterns)

– A class should have only one reason to change (Iterator Pattern, State Pattern)

core design pattern definitions

must for a programmer or designer

Strategy Pattern
This pattern lets you define a family of algorithms, encapsulate each one and makes them interchangeable
Favor composition over inheritance.

Observer Pattern
It defines one to many dependency between the objects so that when one object changes its state, all its dependents are notified and updated automatically

Decorator Pattern
It attaches additional responsibilities to an object dynamically at runtime. Decorators provide flexible alternative to sub-classing for extending functionality.
Note: Decorators should implement the same interface or abstract class as that of the component they are going to decorate.

Factory Method Pattern
It defines an interface for creating and object and lets subclasses decide which class to instantiate. Few guide lines to follow this pattern:
– No variable should hold a reference to the concrete class
– No class should be derived from concrete class
– No method should over-ride and implemented method of the base class

Singleton Pattern
Ensure a class has only one instance and provide a global point of access to it.

Command Pattern
It allows you to decouple the requestor of an action from the object that actually performs an action.

Adapter Pattern
It converts interface of a class into another interface the clients expect. It lets the classes work together that wouldn’t be otherwise possible because of incompatible interfaces.

Iterator Pattern
It provides a way to access the elements of an aggregate object sequentially without exposing its underlying implementation. It also places the task of traversal on the iterator object, not on the aggregate, which simplifies the aggregate interface.

Composite Pattern
It helps us to compose objects into tree structures to represent part whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Façade Pattern
It provides a unified interface to a set of interfaces in a sub system. Façade defines high level interface that makes the subsystem easier to use.
Note: Actually speaking one should invoke methods that belong to:

1. Object itself
2. Objects passed in as a parameter to the method
3. Any object the method instantiates
4. Any components of the object (other object references)

Note: Adaptors and Facades may wrap multiple classes but façade’s intent is to simplify while adaptor’s is to convert the interface to something different

Template Pattern
It defines steps of an algorithm and allow subclasses to provide implementation for one or more steps.
Note: It is a great design tool for creating frameworks where framework controls how something gets done but leaves you to specify what is actually happening at each step of an algorithm. Eg: Array.sort(Obj) imples that Obj should impl Comparable interface.

State Pattern
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

Proxy Pattern
It provides and place holder for another object to control access to it.

All possible ways of implementing singleton pattern and its pros and cons

Here 5 possible ways are discussed
#1

public class Singleton {
 private static Singleton instance;

private Singleton() {
 }

public static Singleton getInstance() {
 if(instance == null) {
 instance = new Singleton();
 }
 return instance;
 }
}

Cons:
Will not suffice for multi threaded environment

#2

public class Singleton {
 private static Singleton instance;

private Singleton() {
 }

public static synchronized Singleton getInstance() {
 if(instance == null) {
 instance = new Singleton();
 }
 return instance;
 }
}

pros:
Will work in single and multithreaded env’s
Cons:
Will be uneccessary overhead once after instance is created for the first time because every time we call getInstance() method we need to acquire lock and release lock which is overhead after instance is available

#3

public class Singleton {
 private static Singleton instance;

private Singleton() {
 }

public static Singleton getInstance() {
 synchronized(this) {
 if(instance == null) {
 instance = new Singleton();
 }
 }
 return instance;
 }
}

pros:
Will not suffice in multithreaded env’s
Cons:
1. Will be uneccessary overhead once after instance is created for the first time because every time we call getInstance() method we need to acquire lock and release lock which is overhead after instance is available
2. There is a chance of more than one thread getting into if(instance == null) block there by creating multiple instances.

#4 (Double Checking)

public class Singleton {
 private static Singleton instance;

private Singleton() {
 }

public static Singleton getInstance() {
 if(instance == null) {
 synchronized(this) {
 if(instance == null) {
 instance = new Singleton();
 }
 }
 }
 return instance;
 }
}

pros:
Will work in multithreaded env’s
Cons:
1. It will not work in prior versions of JDK5.0
2. Double checking is verey pathetic way of implementing Singleton pattern and best practices doesnt suggest to go for this implementation.

#5

public class Singleton {
 private static Singleton instance = new Singleton();

private Singleton() {
 }

public static Singleton getInstance() {
 return instance;
 }
}

pros:
1. Simplest and trusted way as we are leaving the instantiation to the JVM
2. Works in both single and multithreaded env’s