The first step involved in the development of object-based forms consists of learning a little about the Singleton Pattern, because I'll use it within the form generation process.

Probably, this pattern is one of the easiest ones to understand. To clearly explain its definition, let's describe a scenario which developers are frequently confronted with: one object is needed across an application by other objects for doing their work.

Normally, in this situation, it's best to have a single instance of the required object for accessing within the application, instead of having multiple instances of it. To cite a common case, a single instance of a database connection object is required by different objects for them to have database connectivity in their scope.

That's where the Singleton pattern comes in. Why trouble the application with multiple instances of an object, when a single instance is preferred?

Usually, in PHP a class is turned into a Singleton by defining a static method "getInstance()" or even another indicative name, which when called, returns a single instance of the object. Subsequent calls to the method will always return a handle to the object instance.

To clarify things, let's see an example based on the documentation provided in the PHP manual:

class Singleton{

 // $instance holds a single instance of the object
 private static $instance;
 // private constructor
 private function __construct(){}
 // the getInstance() method returns a single instance of the object
 public static function getInstance(){
     if(!isset(self::$instance)){
         $object= __CLASS__;
         self::$instance=new $object;
     }
     return self::$instance;
   }
   public function displayMessage(){
 echo 'I am a Singleton';
   }
}
$singleton=Singleton::getInstance(); //

 return a single instance of the object
$singleton->displayMessage();// display message

The above class represents a simplified version of a Singleton. Notice the use of the static method "getInstance()", which when invoked the first time, returns a single instance of the object. As I said before, recurrent calls to the method will always return a handle to the object. 

 As you'll probably agree, this pattern is fairly understandable. Since this is only a brief overview, further and more complex implementation will be left as an additional task. However, for the purposes of the series, the example is indeed very illustrative.

Now that we've demonstrated the functionality of the Singleton pattern, let's move one step toward the creation of object-based forms and explain the specific role of the Factory Pattern within the developing process.