Warming up Design Patterns - Part 1

Do I really need to refer Design Patterns for cooking good Food?

Too much I can say too much material available for learning Design Patterns aka DP. But very less article directs us when really we need DP and what’s the know how to implement it. DP are nothing but the well defines and proven approach towards achieving some goal in development. Most of the time it adheres to common features available in various languages, but not constrained to any language as such. DP's are well thought out solution to programming problems. These DP's are not evolved overnight but they are the collections of efforts done by various programmers worldwide.

When each developer writes code, he himself has some way for achieving certain solution to problem. He comes with some solution which itself can be a pattern. But here is the mess who can say that what he did is the best solution, or is the only solution to that problem. Again if this is the simple assignment, then it is fine as we will consider "Result is bottom line". But if this is some framework or part of application that is enterprise and need to be extensible and reusable then, it becomes necessity to check that this solution is a proven solution. Here DP comes handy. It assures that it works. And what if there doesn't exist any pattern that matches our problem, and then might be we are one of them who discovered a new pattern. But stop... it's not yet publishable; you have to verify it and make sure that it will work for all such problems. 

In Conclusion and as disclaimer I will repeat the statement of one of author: "Any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior."

Well this is my short J effort to tell what & why DP. Now let’s explore it in more technical way.

Let's cook with Design Patterns

Design patterns are majorly categorized into 3 types depend on where they talk about How to manage types and relation or Creating Object or how the objects are going to communicate with each other to make our design to be scalable with respect of change / addition in underlying algorithms. 

1) Structural: 

These patterns emphasize on relationships between entities. They talk about how classes and objects can be combined to form large systems. Here main thing to note that class and object do differ. Class patterns make use of Inheritance mechanism to provide more useful program interfaces whereas object patterns talks about composing different objects using composition i.e. including object within other object, to achieve the same goal.

2) Creational

These patterns deal with object creation mechanism. The main design goals are how the objects will be created, how the creation of object will be controlled and how to less the impact on client logic when there are frequent changes in the creation logic i.e. decoupling.

3) Behavioral

These patterns more worry about how object should communicate to increase flexibility in communication. It also makes sure the scaling of system with respect to addition/modification in underlying algorithm.

In next part of the article we will elaborate each of these categories in more detail with suitable example.

Marker Interface

"Marker interface is a interface which has no methods to implement"

This is what I learn in my graduation. This is quite strange that why I should implement such stupid interface when it doesn't have a single method. With my target of finishing exam and my over smartness,  that time I assumed that "Sun" guys gone mad and done this stupidity. I scored good marks....

Now when I tried to dig the purpose, the truth is different.

The Marker interface is just a way to mark class that it has certain capability. This mechanism is also referred as "marker interface pattern". This is really important concept as it provides a means to associate metadata with a class where the language does not have explicit support for such metadata. This pattern is supported by all those languages which provide run time type identification of an object. 

Example of marker Interface.

java,lang.Cloneable
java,io.Serializable
java.util.EventListener 

Some key Notes:

1. We can implement our own custom marker interface. e.g. I have some abstract financial classes where currency is important thing. I don't want to handle that which currency need to be used . I may come up with idea of having different marker interface as RupeesMarker, DollarMarker or  EuroMarker, and then I will leave on programmers who inherits my class, to implement any one of above marker interface for required currency. Of course I have already handled the logic in abstract class about for-matter to be used depend on type of marker interface used.
2. The problem with marker interface is once you implement if for some class that tag is automatically inherited by all subclasses, and in this case suppose you don't want to mark it for a purpose superclass did, you don't have a way to "unimplement" the marker. 

Example:

Interface: BossMarker.java

public interface BossMarker {
// My whole purpose in life is to tag, all those classes who implement me, as Boss
}

Abstract Class: Boss.java

public abstract class Boss implements BossMarker {
    {
        if(this instanceof BossMarker)
            System.out.println("Hey I am a " + this.getClass() + " Tagged as Boss");
    }
}

Testing Class: Person.java

public class Person extends Boss {
    public static void main(String arg[]){
        Person p = new Person();
    }
}

Output:

Hey I am a class Person Tagged as Boss

Note: If you disagree to any of above mentioned points, feel free to comment, I will correct if required.

Design Pattern Catalog

1.       Creational Patterns

a.        Abstract Factory

b.       Builder

c.        Factory Method

d.       Prototype

e.       Singleton

2.       Structural Patterns

a.        Adapter

b.       Bridge

c.        Composite

d.        Decorator

e.       Façade

f.         Flyweight

g.        Proxy

3.       Behavioral Patterns

a.        Chain of Responsibility

b.       Command

c.        Interpreter

d.       Iterator

e.        Mediator

f.          Memento

g.        Observer

h.       State

i.          Strategy

j.         Template Method

k.        Visitor

4.       J2EE Patterns

a.        MVC

b.       Business Delegate

c.        Composite Entity

d.       Data Access Object

e.       Front Controller

f.         Intercepting Filter

g.        Service Locator

h.       Transfer Object

5.       Misc

a.        typesafe enum

b.       RESTful WS

Hello World

I love to start my blog with the simplest post ever.....

public class HelloWorld {

static{
System.out.println("Hello World");

System.exit(0);

}

}
 
 
Simple right ???