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 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 better ones. Object…