Decorator Pattern

Attaches additional responsibilities to an object dynamically. Decorators provides a flexible alternative to subclassing for extending functionality.

http://javapapers.com/design-patterns/decorator-pattern/

(abstract class) compontent{

m1();

m2();

}

concreteComponent{

m1();

m2();

}

(abstract) Decorator extends component{

m1();

m2();

}

you can use the decorator to decorate concreteComponent to concreteNewComponent with something additional

Design pattern book 95~98

Beverage beverage = new Espresso();

Beverage beverage2 = new DarkRoast();

beverage2 = new Mocha(beverage2);

beverage2 = new Mocha(beverage2); // double mocha

beverage2 = new Whip(beverage2); // with whip cream

list of few basic design patterns

http://www.scribd.com/doc/42708254/Design-Patterns

quick look when there is no time to do deep reading

adapter design pattern

http://sourcemaking.com/design_patterns/adapter/java/1

http://www.oodesign.com/adapter-pattern.html

Intent

• Convert the interface of a class into another interface clients expect.
• Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

factory pattern

http://www.oodesign.com/factory-pattern.html

• creates objects without exposing the instantiation logic to the client.
• refers to the newly created object through a common interface

Best practices to improve performance using Patterns in J2EE

http://www.precisejava.com/javaperf/j2ee/Patterns.htm

Singleton

public class Aclass{

private static A uniqueInstance;

private Aclass();

public Static Aclass getInstance(){

if(uniqueInstance == null)

uniqueInstance = new Aclass();

return uniqueInstance;

}

}

Strategy Pattern

defines a family of algorithms, encapsulates each one, and makes them interchangeable.Strategy lets the algorithm vary independently from clients that use it.

Class A{
SortInterface i;
}

Interface SortInterface{
sort();
}

Class ConcreteAlgorithm1 implements SortInterface{
sort(){
...
}

}

Class ConcreteAlgorithm2 implements SortInterface{
sort(){
...
}

}

a family of sort algorithms

Design principles

1. Identify the aspects of your application that vary and separate them from what stays the same. Take the parts that vary and encapsulate them,

take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't.

All patterns provide a way to let some part of a system vary independently of all other parts.

2. Program to an interface, not an implementation.

The point is to exploit polymorphism by programming to a supertype so that the actual runtime object isn't locked into the code.

The declared type of the variables should be a supetype, usually an abstract class or interface, so that the objects assigned to those variables can be of any concrete implementation of the supertype, which means the class declaring them doesn't have to know about the actual object type. (page 12)

3. Favor composition over inheritance.
class A{
BehaviorClass1 behavior1;
BehaviorClass1 behavior2;
}

When you put two classes together like this you're using composition. Instead of inheriting their behavior,the class A get their behavior by being composed with the right behavior object.

Not only does it let you encapsulate a family of algorithms into their own set of classes, but it also lets you change behavior at runtime as long as the object you'are composing with implements the correct behavior interface.