Crisps abt Design Patterns

Problems are hard solve more than that, our solution should not make our appln disobey OCP (Open to extensions and Closed to Modifications) but what if they have a quality solution pre-existing :)
That's what design patterns are :P They are generic reusable solutions for commonly occuring problems in S/W Design
Design patterns are of various categories if u wanna know them in detail follow the link below 
 Design Patterns  :)
I was just going thro some of the most commonly used Design Patterns in PHP and I wish to give them all a small introduction

Singleton:  
A common scenario for this is a LOG BOOK.

We might be recording various events at various times. So, whenever we need to record 
something we ll be declaring an object for the log book class and will be WRITING using some member functions of it. 
But what if we want a "GLOBAL LOG BOOK" for entire appln? Then choose singleton patterns. 
This pattern allows instantiation of object for a class only once. 
For Further instantiations, reference of the previously created object ll be returned. 
(Now Logbook is updated not created and written everytime)
One more appln is single player(only object of the whole app) gaming 

Google can find U PHP implementation of Singleton easily but i'll plot one for u here
class LogBook
{
  private static $LogBookObject;
  private function __construct(){...}
  public static function createInstance()
  {
     if(self::$LogBookObject==null)
     {
        self::$LogBookObject=new LogBook();
     }
     return self::$LogBookObject;
  }

  public function updateLog($msg){...}
}
$LogBookObject = LogBook::createInstance();
$LogBookObject->updateLog("This Works");
Factory:  
Huh!!! Its like ordering food to a waiter in a hotel :P 
Here waiter is an abstract object but the concrete object is the chef :) 
U might order Veg/Non-Veg the waiter decides to whom the order should be placed. 
The main advantage of it is the customer never knows even the hotel changes the chef :D

Let us design a hotel appln in the sameway :)
class VegChef
{
  public function __construct() {}
  public function makeVegFood($foodName){}
}
class NonvegChef
{
  public function __construct() {}
  public function makeNonvegFood($foodName) {}
}
class Waiter
{
  private function __construct(){}
  public static placeOrder($foodType)
  {
    if($foodType=="Nonveg")
        return new NonVegChef();
    else if($foodType=="Veg")
       return new VegChef();
  }
}

$orderFood=Waiter::placeOrder("Veg");

$orderFood->makeVegFood("Gobi");
Strategy:  
This is like a music player that chooses songs based on our mood :P 
Here our behaviour like happy, romantic, sad are implemented as different classes hence any changes in happy never mess up with sad :D
User ll also be able to change his mind with no intervention

Lets go for implementation now
class ImHappy
{
  public function playSongs(){Algo to choose songs}
}
class ImSad
{
  public function playSongs(){Algo to choose songs}
}
class IfeelRomantic
{
  public function playSongs(){Algo to choose songs}
}
class musicPlayer
{
  private $Choice;
  public function setMyChoice($Choice)
  {
    $this->Choice=$Choice;
  } 
  public function Play()
  { 
   $this->Choice.playSongs()
  }
}

$user=new musicPlayer();
$user->setMyChoice(new ImHappy());
$user->Play();
// Ha I feel Romantic :P
$user->setMyChoice(new IfeelRomantic());
$user->Play();
There are two more  Observer and Chain of command  out of five I read :) 
Will soon comeup with nice illustrations for them :)