Thursday, December 15, 2011

Basic Patterns Catalogue

Summarising key patterns used in development for reference.

A Pattern is a solution to a problem in a context.

An Anti-Pattern tells you how to go from problem to a bad situation.

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

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

Use Bridge Pattern to vary not only your implementation, but also your abstraction.

Use Builder Pattern to encapsulate the construction of a product and allow it to be constructed in steps. It encapsulates the way a complex object is created.

Use Chain of Responsibility Pattern when you want to give more than one object a chance to handle a request.

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.

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.

The Decorator Pattern attaches additional responsibilities to an object dynamically. It provides a flexible alternative to subclassing for extending functionality.

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher level interface that makes the subsystem easier to use.

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.

Use the Flyweight Pattern when one instance of a class can be used to provide many “virtual instances”.

Use Interpreter Pattern to build an interpreter for a simple language.

The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Use the Mediator Pattern to centralise complex communications and controls between related objects. It can become overly complex without proper design.

Use the Memento Pattern when you need to be able to return an object to one of its previous states, e.g. if your user requests an “undo”.

Use the Prototype Pattern when creating an instance of a given class is either expensive or complicated.

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

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

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

The 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.

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.

Use the Visitor Pattern when you want to add capabilities to a composite of objects and encapsulation is not important.

Please refer http://c2.com/ppr/ for more on patterns.

Tuesday, December 13, 2011

Force.com: What Gives?

When Salesforce.com came up with Force.com, briefly I did nurture the illusion that they wanted to make the new platform for the web. Too bad it turned out to be a marketing gimmick to tap into a wider creative potential. Brilliant strategic move, but not what I had hoped it would become.

Force.com licenses are now paid and Salesforce is coming up with a financial software. Too bad its Chatter and related ideas didn't amount to much eventually. Nevertheless, as a company it has a good future. I only rue that it could have really worked on making Force a platform for the web. That, however, would have needed a paradigm shift in business strategy. So, in a way, the company has come back to its roots; not letting itself being deluded by grandiose ideas about social networking.

Paying for Force.com is like being sold Java and then being expected to pay for it (thank God that didn't happen!): doesn't feel good. Business, however, is not about feeling good: it is about profit. Perhaps that's why Oracle bought Sun while Salesforce continues its growth saga. On behalf of people who support open-source, I can only say: RIP, Force.com (hopefully)!

Tuesday, November 29, 2011

10 Design Principles

Was going through my older notes, brushing up some technical bits. My first book for design patterns was the original book by the Gang of Four. However, the book that helped me understand Design Patterns the best was Head First Design Patterns. Following are the key design principles summarised in the book:
  1. Identify the aspects of the application that vary and separate them from what stays the same: use encapsulation.
  2. Program to an interface, not an implementation
  3. Favour composition over inheritance
  4. Strive for loosely coupled designs between objects that interact
  5. While inheritance is powerful, it does not always lead to the most flexible or maintainable designs
  6. Code should be closed to change but open to extension
  7. Principle of least knowledge: talk only to your immediate friends. Only invoke methods that belong to:
    • The object itself
    • Objects passed in a parameter to the method
    • Any object that the method creates or instantiates
    • Any components of the object
  8. Depend upon abstractions. Do not depend upon concrete classes
    • Avoid variables that hold reference to a concrete class (use Factory)
    • Avoid deriving class from concrete classes
    • Avoid overriding any of the implemented methods of a base class
    • You can ignore these guidelines if the class is highly unlikely to change
  9. Hollywood principle: don’t call us, we’ll call you. Low level components can hook into the system, but high level components determine when they are needed.
  10. A class should have only one reason to change
I have put this blog for my own reference, but hope it helps somebody else as well. To learn more, you will have to refer Head First. In next few posts I will summarise key design patterns as described in the book.