Web Technology

Factory Method Pattern:
In software development, a Factory is the location in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage. Factory methods encapsulate the creation of objects. This can be useful if the creation process is very complex, for example if it depends on settings in configuration files or on user input. This method provides a common point for instantiation of any of the various classes depending on certain factors (often decided by configuration). It abstracts the process from the system. These classes implement a set of methods which are declared to the system either via an abstract class or an interface. By
forcing this constraint, we can be rest assured that provided an object, the methods executed against it by the system will correspond accordingly.

This can be very useful in certain cases, for example suppose we are required to design a database-operation package which is database independent . For this we want our codes, using the package not to get effected even if database shifts from one technology to the other. Let's say today we are using My Sql, but even if tomorrow we decide to go with Oracle we, should not be required to change our code. This flexibility can be easily achieved by employing Factory Method Pattern.

So first we will make an interface, declaring all the important methods, which we want to be defined in each and every class under this package. So our code would like something like,

Interface DB_Gateway
{
 public function AddQuery();

 public function ExecuteStep();

 public function RollBack();

 public function GetError();
}

Now once we have this interface we will make every class associated with database operation to implement it. Now we could have classes dedicated to database technology. For example we can design a class exclusively for MySql and so on.

The one for My Sql will be something like:

class cMySql Implements DB_Gateway
{
 
 private $strDBName;
 
 private $strUserName;

 private $strPWD;

 private $cHandle;

 private $strQuery;

 private $strStatus;
 
 private static $stExists = NULL;


 public function AddQuery($query)
 {
  //implementation here...
 }
 
 public function ExecuteStep()
 {
  //implementation here...
 }
 public function RollBack()
 {
  //implementation here...
 }
 public function GetError()
 {
  //implementation here...
 }
 ....
 ....
}

similarly we can have more classes dedicated to the database technology.

Now we can have a class which would supply the correct object depending on the database technology configured. So our decider class would look like this:

class ObjDecider
{
  
 private $strHost;
 private $strDBName;
 private $strUserName;
 private $strPwd;
 private $strType;
 private $strVer;

 public function SetType($type)
 {
   $this->strType = $type;
 }
 
 
 /*
 * This method will return the correct object depending the type set in config
 * 
 * @return object
 */

 public function GetObject()
 {
  $objDB = '';

  switch($this->strType)
  {
   case 'MySql':
      $objDB = cMySql::Initialize($this->strHost, $this->UserName, $this->Pwd, $this->DBName);
      break;
   // and so on.....
  }
  return $objDB;
 }
}
 

So now we need not worry about changing the codes anywhere as we know that all the objects will support all the methods defined and will work in same manner irrespective of database. So here we have abstracted the inner layout. So the real task and implementation is abstracted and hence better OOP approach.

That's all for the day...will get back with some more patterns soon....