BlogDesk?
Wednesday, November 11th, 2009Trying BlogDesk for posting …
Archive for November, 2009
Singleton Design Pattern
Thursday, November 5th, 2009Issue no. 3 on design patterns: The singleton pattern.
Whenever we need a place to save and retrieve data throughout a script without using globals the singleton pattern comes in handy. It allows only one instance of itself. What seems like a drawback is quite useful: Wherever in your source you instantiate such an object: You can be sure that you’ll always get the instance of the same object. Remember the parameterized factory from the last chapter? Every time we wanted to create a new database-access-object we had to pass “mysql” or “pgsql” to the create-method. Wouldn’t it be easier if we just saved the database type to a singleton and retrieved it everytime we need it?
//------------------------------------------------
// Singleton
//------------------------------------------------
// Definition
class Singleton
{
// "This is a handle to myself"
private static $instance;
// database type
public $dbtype = "";
// Private clone-function and private constructor
// make sure, that nobody can clone the object or
// instantiate it using the standard constructor.
private function __construct() {}
private function __clone() {}
// This one returns the instance handle to itself.
// It's static, because it has to be accessible
// before any object is available
public static function GetInstance()
{
// "Am I already existing?"
if (!isset(self::$instance))
{
// "No? Create myself and save the handle
// to myself."
$class = __CLASS__;
self::$instance = new $class;
}
// "Return handle to mysqlf"
return self::$instance;
}
}
// ...
// somewhere in our code
function SetupScript()
{
// Get handle to our singleton object
$GlobalInfos = Singleton::GetInstance();
// Set the $content variable to 42
$GlobalInfos->dbtype = "mysql";
}
// ...
// somewhere else in our code
SetupScript();
// ... deep down in the code
// Get handle to our singleton object
$Registry = Singleton::GetInstance();
// Remeber that from the last chapter?
$myDbObj= MyClassFactory::Create($Registry->dbtype);
Parameterized Factory Desing Pattern
Sunday, November 1st, 2009
Deprecated: Function split() is deprecated in /var/www/l3s6524/html/datensarg/wordpress/wp-content/plugins/google-analytics-for-wordpress/gapp/googleanalytics.php on line 391
Deprecated: Function split() is deprecated in /var/www/l3s6524/html/datensarg/wordpress/wp-content/plugins/google-analytics-for-wordpress/gapp/googleanalytics.php on line 391
The parameterized factory design pattern is an extension to the factory design pattern as you might have guessed, but here we can make the factory create different objects depending on the parameter passed to the create-method. Imagine your application is supposed to connect to a MySQL-DB or to a PostgreSQL-DB. Instead of creating different objects in your code you might just want to pass “mysql” or “pgsql” to the create-method and you get the class needed for the specific database.
//------------------------------------------------
// Parameterized Factory
//------------------------------------------------
// Definition
class DbMySQL
{
public $content= "I am MySQL!\n";
}
class DbPgSQL
{
public $content= "I am PostgreSQL!\n";
}
class DbFactory
{
public function Create($dbtype)
{
switch($dbtype)
{
case "mysql":
return new DbMySQL();
break;
case "pgsql":
return new DbPgSQL();
break;
}
}
}
// Usage
$myFirstObj= MyClassFactory::Create("mysql");
$mySecondObj= MyClassFactory::Create("pgsql");
echo $myFirstObj->content; // "I am MySQL!"
echo $mySecondObj->content; // "I am PostgreSQL!"