Skip to main content

Posts

Showing posts from June, 2008

Factory Method

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()
  {
returnnew MyConcreteObject();
  }
}


class MyOtherConcereteObjectCreater : Creator
{
virtual MyObject CreateObject()
  {
returnnew MyOtherConcreteObject();
  }
} Now the module which requires different flavours of MyOb…

Creational Patterns

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 )

Common Software Design Blunders

I have been reviewing some of the codes at work (mostly my own ;) ). We tend to make a lot of mistakes especially when we have not put through enough thinking before 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 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 wit…