Friday, February 24, 2012

More Patterns-2

The Decorator Pattern attaches additional responsibilities to an object dynamically. It provides a flexible alternative to subclassing for extending functionality.
Decorators (java.io is a good example):
  • Have same supertype as the objects they decorate
  • You can use one or more decorators to wrap an object
  • Objects can be decorated at runtime
  • The decorator adds its own behaviour either before and/or after delegating to the object it decorates to do the rest of the job
  • Can make code complex and cause problems if not well-thought, need to be careful before using it
Decorator pattern = responsibility. New responsibilities or behaviours are added to the design, without altering existing code.

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which classes to instantiate. Factory Method lets a class defer instantiation to subclasses.

Factory employs two parallel class hierarchies: the creator classes and the product classes. The pattern isolates object creation and reduces object dependency.

he Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.

To prevent problems with multi-threading in Singleton creation, you can:
  • Synchronise the getInstance method. This is expensive, but is easy and can be done if we don’t expect it to be called many times
  • Use eager instantiation of the instance, if that is not too expensive and we expect Singleton to be definitely used early on
  • Use “double-check locking”. Can be done only in Java 5 and greater and can be an overkill
public class Singleton {
    private volatile static Singleton uniqueInstance;
    private Singeton() { }
    public static Singleton getInstance(){
        if(uniqueInstance==null){
            synchronized(Singleton.class){
                if(uniqueInstance==null){
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

The Command Pattern encapsulates the request as an object, thereby letting you parameterise other objects with different requests, queue or log requests, and support undoable operations.
Think of command as a waiter carrying requests from customer to chef for execution. Command itself does less work, with most of the work offloaded to an encapsulated class.
public interface Command {
 public void execute();
}


Monday, February 13, 2012

More on Patterns - 1

Useful reminders for some useful patterns:

The Template Method Pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. It lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

The Template Method Pattern ensures that the algorithm lives in only one place.

A hook is a method declared in the abstract class containing the template, but given an empty or default implementation. It can be used to help the subclasses to conditionally control the flow of the algorithm, or implement/skip an optional part of the algorithm.

A lot of people use this pattern, especially for making frameworks.

Factory Method is specialisation of Template Method

Strategy and Template Method Patterns both encapsulate algorithms, one by inheritance and one by composition

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and composition of objects uniformly.

Composite Pattern often used in UI design.

If the composite structure is complex or expensive to traverse, it may help to use caching.

There are trade-offs in implementing Composite: need to balance transparency and safety with your needs.

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

Strategy and State look very similar, but differ by intent. Think of Strategy Pattern as a flexible alternative to subclassing. You change the behaviour by composing with a different object. Think of State Pattern as an alternative to putting a lot of conditionals in your context. You can simply change the state object in the context to change its behaviour.

The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.

Remote Proxy controls access to remote objects (RMI), Virtual Proxy controls access to resources expensive to create (loading messages), and Protection Proxy controls access to resources based on access rights (Java dynamic proxy).