a Programmer's journal

A nice blog for all new googlers. Gives useful informations and hacks on how to create effective blogs and to monetize your existing ones. I liked it.

In this design pattern, a contract is defined for creating an object. All derieved classes who implements this policy(via virtual method or implementing an interface ) decide which object in a class heirarchy to instantiate. class  Creator {    virtual  MyObject CreateObject(); } Creator defines a contract that all its derieved classes expose a method "CreateObject" which should return an object which "IS" a MyObject. class  MyObject { } class  MyConcreteObject : MyObject { } class  MyOtherConcreteObject : MyObject { } MyConcreteObject and MyOtherConcreObject are different flavour of MyObject.Each of the class share IS relationship with MyObject. Let's implement few "Creators". class  MyConcereteObjectCreater : Creator {    virtual  MyObject CreateObject()   {       return   new  MyConcreteObject();   } } class  MyOtherConcereteObjectCreater : Creator {    virtual  MyObject CreateObject()   {      return  

Creational design patterns abstract the instantiation process. Introducing this design patterns makes a system independent of how its objects are created and composed. Two major responsibilities of Creational patterns are: To encapsulate the concrete classes that system uses. To encapsulate how instances of these classes are created. Factory Method: Creates an Instance from a several derieved classes Abstract Factory: Creates Instance from several family of related classes. Builder: Separates object instantiation from object representation. Prototype: A single object is copied and cloned. (.. to be continued in detail )

I have been reviewing some code at work (mostly my own ;) ). We tend to make a lot of mistakes, especially when we have not thought through and we start writing code, only to regret later. Here are my favourite ones. Explicit object Instantiation: If your design involves instantiating objects from concrete classes, then there's a flaw already. This commits an application to a particular implementation instead of a particular interface, it complicates future (unavoidable) changes. Visibility to  Implementation: If a calling module knows how a library is represented or Implemented, it tends (rather unknowingly) to a design a system which is more specific to the implementation. Hiding this information from the client is a better design because even if the implementation of the object used is changed or altered, there are no cascading changes on the client. Algorithmic Dependencies: Algorithms are prone to changes in the name of optimization and often are replaced with bette