Recently a blog post made by another “programmer” had caught the eye of another Brampton area developer as well as mine once it was shared. The post was absolutely horrible and contained some misdirected information specifically for a blog which focus is on helping you become a better programmer. Let me first denote that this blog post that I am writing (not the one I will be referring to) is not being written for discouragement to the other blogger. This post is simply to let him and others know that refusing to learn from others by being stubborn will not get you no where and for the fact of providing proper information regarding incorrectly misdirected information. The other Brampton area developer also has written a response to this incorrect blog posting titled “Top 10 PHP Techniques That Will Save You Time and Effort” which can be found here.

The response blog article that Sean posted corrected a lot of information that was incorrect and misdirected within the blog post by Spyros P. I am not going to re-iterate the same information that Sean did as you can read his response yourself but I will re-iterate a couple of key points to hopefully correct help Spyros realize his misunderstanding.

Within Spyros post, the second item within his list of techniques is “Use the Request Global Array to Grab Data”. Well, this is a good title – but his explanation on why to use it is very misguided and can cause beginner programmers to get very confused and cause major problems. Here is the snippet from his blog posting regarding the reasoning to use the $_REQUEST global.

There is actually no reason to use $_GET and $_POST arrays to grab values. $_REQUEST, is another global array that fetches you either a get or form request. Therefore, it’s most times more convenient to use something like this to parse data :

$action = isset($_REQUEST['action']) ? $_REQUEST['action'] : 0;

Let me draw your attention to the documents on this HTTP global variable which is located here.

Let’s first look at the concept of this variable and possible security and code integrity problems it could bring to your application.

  1. Since the release of PHP 5.3, this global variable is now drastically effected. The reason of this is in the release of PHP 5.3, there has been a new PHP INI directive that has been introduced called request_order. The problem that this can cause is that element values can be overwritten based on another global array variables data which can result into incorrect data being used if you assumed that you were going to be getting the correct data from a $_POST element but instead got it from $_GET or $_COOKIE (if $_COOKIE was included – which it is not by default).

    A quick example to explain this a bit further. Say you have a HTML form which uses the method POST which on submit posts the field ‘x’. However, at the same time your action URI also expects the that there is an ‘x’ query string parameter available. Now, any good programmer (or at least a logical one) would say okay, I will use the appropriate $_POST and $_GET arrays to retrieve the appropriate data. However, based on what Spryos has said and suggested is to use $_REQUEST instead. Yikes! What will happen? Will data be overwritten? I do believe so. So, what will happen is that $_REQUEST will contain only a single element with the key value of x. But how do you know which data it contains? Either way, you are screwed to say the least simply because you now do not have all data to correctly proceed.

  2. Others had mentioned that this is a security problem? And yes sir it can be. Why is this? Well this is simply because now that you are using $_REQUEST instead of the appropriate global arrays instead – you are now leaving yourself open to attacks based on incorrect data retrieved from the wrong source.

On to the second thing that Spyros incorrectly describes which is the use and description of the Singleton Design Pattern Let me make this clear, this pattern known as the Singleton is used to restrict instantiation of a class to ONE object.

Here is to reference what Spyros wrote:

10. When You Need Just an Object, Use a Singleton Pattern

It happens pretty often in PHP that we just need a single object created one time and then used globally throughout our whole program. A good example of this is the smarty variable that has to be initialized once and then is used all over the place. A good way to do that is a Singleton pattern, where an object is just created once and for all. The way to do this is like :

function smartyObject()
{
	    if ($GLOBALS['config']['SmartyObj'] == 0)
	    {
	        $smarty = new SmartyGame();
	        $GLOBALS['config']['SmartyObj'] = $smarty;
	    }
	    else
	        $smarty = $GLOBALS['config']['SmartyObj'];
	    return $smarty;
}

Notice that we have a global smarty variable (initialized in config.php in example) and if it equals 0, we go about creating a new smarty object. If not, it means that the object is already created and we just need to return it.

The problem with his information is that his implementation of the singleton is incorrect but the concept is correct. What he is trying to do is limit the number of instances available for the class “SmartyGame”. However, the class itself does not contain any logic or handling of this therefore results in an incorrect use of the Singleton concept. This itself can lead to many problems such as performance issues, data integrity issues, etc.

The reason that his example is incorrect is that I am still able to go to another section of code within the script and create another instance of of the SmartyGame class by simply saying using the new keyword. An example:

new SmartyGame();

To correctly use the Singleton design pattern, the logic must be implemented within the class itself. A few notes on doing so correctly is:

  • Visibility modifier of constructor should be private.
  • A final static method should be created used to create the instance of the object.
  • Only a single instance should be allowed to be created – therefore within threaded environments, assure that you correctly lock the current thread while creating the instance so there is no thread switch while instantiating.

A simple example of a Singleton design pattern implementation for PHP can only correctly be implemented since PHP 5.3 and the use of late static binding. However, a common solution is available for versions less then PHP 5.3 but a PHP 5.3 solution is provided here. Simply create a static class known as “Singleton” which is abstract and that all derived classes will use the Singleton design pattern concept. The abstract class named Singleton is available below:

/**
* Singleton
*/
abstract class Singleton
{
    /* Member variables */
    private static $instances = array();

    /**
    * getInstance
    *
    * Handles the instantiation and retrieval of an instance of this object.
    *
    * @access:  public
    * @param:   void
    * @return:  Singleton
    */
    final public static function &getInstance()
    {
        $calledClass = get_called_class();
        if( !isset(self::$instances[$calledClass]) )
        {
            self::$instances[$calledClass] = new self();
        }

        return self::$instances[$calledClass];
    }

    /**
    * __clone
    *
    * @access:  private
    * @param:   void
    * @return:  void
    */
    final private function __clone()
    {
        /* void */
    }

    /**
    * __construct
    *
    * @access:  protected
    * @param:   void
    * @return:  void
    */
    abstract protected function __construct();
}

Now, I will stop with correcting the wrong here. However, let me go on to say that I was very appalled by the number of ridiculous comments that were made directed at others from Spyros regarding there criticism and correction. The problem with these comments were that it appeared to me that Spyros really did not give a damn about what others had to say and he put himself high up on that ivy pedestal. So what am I basically saying here? It looked like Spyros did not take the criticism and comments too well when he was being correct. By why is this a problem? The problem is simply that he was doing it wrong and advising others to do it wrong also. What should have occurred was he should have said thank you for the comments (which he did for the most part) and looked up what he believed to be false and check to assure that he was correct which he would have found that he was not. Learning from others within this industry or any industry for that fact of the matter will only get you places. If you assume and sit yourself up on that ivy pedestal, you will soon come to find out that many will not be there for when you need us and you will learn that you do not get to far with that kind of mind set.

Anyways, I will shut-up now as there is work to be done. However, I hope that all will understand why I have posted this article along with the fact that there is a deeper meaning behind that I probably did not express too well other then just correct Spyros.