PHP Example: The Strategy Pattern

Even though we liked the old color scheme of the phppatterns.com site better than the new one, we think the content is still aces. One of our favorite areas is the design section with it’s excellent examples of various design patterns written in PHP.

One pattern that we find ourselves using repeatedly is the Strategy Pattern. The Strategy Pattern is one of the original Gang of Four design patterns. The Strategy Pattern is grouped with other behavioral patterns because it’s best suited to solving problems that affect the behavior of your program.

You can define the Strategy Pattern like so:

Encapsulate various related algorithms in individual subclasses of a common superclass.*

You might wonder why this would offer a solution that affects the behavior of your programs. Here’s the beauty of this pattern - if you’ve ever found yourself writing lots of if-else if-else blocks, or if you’ve ever written loads of long switch or case statements, then you’re going to love this thing. I’m not saying you won’t have if-blocks, but you’ll find that your code will become much cleaner and more flexible if you start applying some Strategy. Read on for the example.

The Strategy Pattern example on the phppatterns.com site, described here, uses something pretty common in web application programming - form validation. That’s the example we’ll use - and extend here.

Web applications are often filled with HTML forms, and these forms can often have many fields. It’s pretty common to have the web application validate the data submitted in these fields on the server - and this is often in addition to client (or browser) based field validation. This is usually a response to the ability that users have to disable javascript within their browser, opening up the possibility to completely bypass client-based validation.

So - let’s consider a simple form for user registration. In this application, you only have three fields that you’re concerned with - the user name, the password, and a second password field that you’ll use to confirm the user typed their password correctly. Told you the form was simple. Now, let’s look at the requirements - which are anything but simple:

Let’s assume your customer’s requirements are to make all three fields required for new users. For existing users, only username is required - but if a user enters a password, then the confirmation password field will also be required. In all cases, user names and passwords must be between 6 and 20 characters, can only contain letters and numbers (no punctuation), are case sensitive, and of course, the password and confirmation passwords must match one another. Finally - user names must not already exist in your user database. That’s quite a bit of business logic for such a trivial form, but you’ll probably find that the business rules that are important to your clients often provide you with the most complex challenges.

So let’s assume you have already created the form, and the logic to write the data into the database, and you’re ready to apply these business requirements.

You might be tempted to start off thinking in terms of if-then or case statements. I won’t even bother with the sample code because I want you to stop thinking that way - so I won’t enable your addiction to long, buggy, complex if-else if blocks.

Instead, let’s look at how we can apply the Strategy Pattern. Remember, we defined the strategy pattern is about encapsulating related algorithms in subclasses of a common abstract class, and we clearly have several related algorthms. In the one case, we have an algorithm for validating the username field. In the other case, we have an algorithm for validating the password (and confirm password) field. We also have an algorithm for validating whether any arbitrary required field is present or not. So - by the Strategy pattern - three related algorithms would mean three related subclasses.

What do these related classes have in common? In all cases, they encapsulate logic to validate a form field. So, we’ll start with with an abstract FieldValidator class - and create a simple interface: we’ll just have a validate() method that gets called during object construction. The validate method will check the business rules for the current subclass, and add any errors it encounters to the errorMsg list. We’ll also add an isValid() mathod that checks the error list and returns true if there are no errors. If validation fails, the validation error(s) for the current field will get recorded in an array of error messages that we can display back to the user with a getError() method. Once we have defined the superclass, we’ll then create three subclasses - one for the username, one for the password, and one for any required field. The UML for the FieldValidator strategy is presented here in the figure to the left.

Now that we’ve got the various classes defined, lets write the code. While this bit is almost identical to the PHPPatterns.com example, we’ll get to the extension shortly.

<?php


/**


 *  FieldValidator 


 * 


 * "Abstract" superclass for form field validation


 * Example of the Strategy Pattern presented on 


 * phppatterns.net


 */


class FieldValidator {


    /**


    * Private


    * $errorMsg stores error messages if not valid


    */


    var $errors;

 

    //! A constructor.


    /**


    * Constucts a new FieldValidator object


    */


    function FieldValidator() {


        $this->errors=array();


        $this->validate();


    }

 

    //! A manipulator


    /**


    * @return void


    */


    function validate() {


        // Superclass method does nothing


    }

 

    //! A manipulator


    /**


    * Adds an error message to the array


    * @return void


    */


    function setError ($msg) {


        $this->errors[]=$msg;


    }

 

    //! An accessor


    /**


    * Returns true if string valid, false if not


    * @return boolean


    */


    function isValid () {


        if ( $this->errorMsg != null && sizeof($this->errorMsg ) > 0 ) {


            return false;


        } else {


            return true;


        }


    }


 


    /**


    * Pops the last error message off the array


    * @return string


    */


    function getError () {


        return array_pop($this->errorMsg);


    }


}


?> 

And now, the three subclasses

<?php


/**


 *  RequiredFieldValidator subclass of FieldValidator


 *  Validates a that a required field is present 


 */


class RequiredFieldValidator extends FieldValidator {


    /**


    * Private


    * $user the fieldName to validate


    */


    var $fieldName;

    

    /**


    * Private


    * $user the fieldName to validate


    */


    var $fieldValue;


 


    /**


    * Constucts a new Validator object


    * @param $fieldName the Name of the Field


    * @param  $fieldValue The Value of the Field


    */


    function RequiredFieldValidator ($fieldName, $fieldValue) {


        $this->fieldName=$fieldName;


        $this->fieldValue=$fieldValue;


        FieldValidator::FieldValidator();


    }


    /**


    * Validates the field is present


    * @return void


    */


    function validate() {


        if ( $this->fieldValue  == null || “”== $this->fieldValue ) 


        {


            $this->setError($this->fieldName . ‘ is a required field.’);


        }


    }


} 


/**


 *  UserNameValidator subclass of FieldValidator


 *  Validates a username


 */


class UserNameValidator extends FieldValidator {


    /**


    * Private


    * $user the username to validate


    */


    var $user;

    

    /**


    * Constucts a new ValidateUser object


    * @param $user the string to validate


    */


    function UserNameValidator ($user) {


        $this->user=$user;


        FieldValidator::FieldValidator();


    }

   

    /**


    * Validates a username


    * @return void


    */


    function validate() {


        // do we have OK characters?


        if (!preg_match(‘/^[a-zA-Z0-9]+$/’,$this->user )) {


            $this->setError(‘User Login is null or contains invalid characters’);


        }


        // do we meet minimum length requirement?


        if (strlen($this->user) < 6 ) {


            $this->setError(‘User Login mut be at least 6 characters’);


        }


        // do we meet the max length requirement?


        if (strlen($this->user) > 20 ) {


            $this->setError(‘User Login is too long’);


        }


        // does the current username already exist?


       	if ( $this->user != null && $this->alreadyExists( $this->user ) )


       	{


            $this->setError(‘The User Login, "’.  $this->user .‘" is already in use’);


       	}


    }


	// alreadyExists - return true if the user name is in the DB    


    function alreadyExists( $userName )


    {


      // we’ll leave it to you to determine how implement this method as an exercise.


    }


}


/**


 *  ValidatorPassword subclass of FieldValidator


 *  Validates a password


 */


class PasswordValidator extends FieldValidator {


    /**


    * Private


    * $pass the password to validate


    */


    var $pass;


    /**


    * Private


    * $conf to confirm the passwords match


    */


    var $conf;

 

    //! A constructor.


    /**


    * Constucts a new ValidatePassword object subclass or FieldValidator


    * @param $pass the string to validate


    * @param $conf to compare with $pass for confirmation


    */


    function PasswordValidator ($pass,$conf) {


        $this->pass=$pass;


        $this->conf=$conf;


        FieldValidator::FieldValidator();


    }

 

    //! A manipulator


    /**


    * Validates a password


    * @return void


    */


    function validate() {


        if ($this->pass!=$this->conf) {


            $this->setError(‘Passwords do not match’);


        }


        if (!preg_match(‘/^[a-zA-Z0-9_]+$/’,$this->pass )) {


            $this->setError(‘Password is null or contains invalid characters’);


        }


        if (strlen($this->pass) < 6 ) {


            $this->setError(‘Password must be at least 6 characters long’);


        }


        if (strlen($this->pass) > 20 ) {


            $this->setError(‘Password cannot be more than 20 characters’);


        }


        if (strlen($this->conf) < 6 ) {


            $this->setError(‘Confirmation Password must be at least 6 characters long’);


        }


        if (strlen($this->conf) > 20 ) {


            $this->setError(‘Confirmation Password cannot be more than 20 characters’);


        }


    }


}


?> 

This is roughly the point at which the example on the phppatterns.com ends. After introducing the Strategy Pattern, and then providing the field validator examples, you’re given a little bit of code that shows you how to call you new validator classes. What would have made this an even better example is the recognition that, in addition to the tasks of field validation, you could just as easily apply the Strategy pattern to the task of form validation.

Remember our business requirements? Our requirements in this example say that some of the fields are required for new users, but different fields are required for existing users. Once again, we have related algorithms, which, in this case, are the individual form level validation requirements. In our example, the related “forms” are the new user form and an existing user form. Regardless of whether you actually use different HTML forms for these, you can think of their validation requirements distinctly - and can represent them as concrete implementations of a common FormValidator superclass.

Our new FormValidator class allows you to register new FieldValidator instances to it using the addValidator() method, and provides the abiity to call the validate() method on each one through the isValid() call. Let’s see how this code plays out:

<?php


/*


 * FormValidator


 * 


 * Abstract class that performs field-level validation


 * for a given HTML form.


 *  


 */


class FormValidator


 {


 	var $errors;


 	var $validatorList;

 	

 	function FormValidator()


 	{


 		$this->validatorList = array();


 	} 


 	/**


 	 * validate


 	 * 


 	 * Main abstract method that needs to be implemented in 


 	 * each subclass


 	 */


 	function validate()


 	{


	   $returnVal = true;


	   // Perform validation


	   // against each validator in the list


	   // every one must return true for this method


	   // to return true


 	   foreach($this->getValidators() as $validator) 


    	   {


      	  	if (!$validator->isValid()) 


        	{


        	    $returnVal = false;


        	    while ($error=$validator->getError()) 


            	   {


                       $this->addError($error);


            	   }


        	}


    	   }


    	   return $returnVal;


 	}

 

	function getErrors()


 	{


 		return $this->errors; 


 	}

 

 	function addError($message)


 	{


 		$this->errors[] = $message;

 	

 	}

 

 	function addValidator(& $validatorObject)


 	{


 		$this->validatorList[] = $validatorObject;


 	}


 


        function getValidators()


        {


                return $this->validatorList;


        }


 }


 


?> 

And now, let’s examine the FormValidator subclasses - for the New and Existing user forms.

<?php


/*


 * NewUserFormValidator


 * Validates that the business rules for new user form submissions are followed


 */

 

 class NewUserFormValidator extends FormValidator


 {


 	function NewUserFormValidator()


 	{


 		parent::FormValidator();


 		$this->addValidator( new PasswordValidator($_REQUEST[‘passWord’],$_REQUEST[‘confirmPassword’]));


		$this->addValidator( new UserNameValidator($_REQUEST[‘userName’]));


 	 	$this->addValidator( new RequiredFieldValidator(“Password”, $_REQUEST[‘passWord’]));


 	 	$this->addValidator( new RequiredFieldValidator(“User Login”, $_REQUEST[‘userName’]));

 		

 	}


 }


/**


 * ExistingUserValidator - 


 * This is a formvalidator subclass that gets called when 


 * a user record is updated


 */


 class ExistingUserFormValidator extends FormValidator


 {

 

	function ExistingUserFormValidator()


 	{


		parent::FormValidator();

		

		$this->addValidator( new RequiredFieldValidator(“User Login”,$_REQUEST[‘userName’]));


 


		// only validate password and the confirmation password if either one is present


		if( $_REQUEST[‘passWord’] != “” || $_REQUEST[‘confirmPassword’] != “”)


 	 	{	


	 	 	$this->addValidator(new RequiredFieldValidator(“Password”, $_REQUEST[‘passWord’]));


 		 	$this->addValidator(new RequiredFieldValidator(“Confirmation Password”, $_REQUEST[‘confirmPassword’]));


 		 	$this->addValidator(new PasswordValidator($_REQUEST[‘passWord’],$_REQUEST[‘confirmPassword’]));


 	 	}


 	}


  }


?> 

Now that the various building blocks are in place, let’s see how we might tie this together in our page controller script. You’re probably using some kind of MVC pattern for your system, right? At the controller level - all we’re really concerned with is if we’re dealing with a new or existing user. For new users, we’ll utilize the NewUserFormValidator to do the validation - and if it’s an existing user, we use the ExistingUserFormValidator. Let’s say we have already implemented a method to decide which validator to use. Maybe the User BusinessObject could tell us based on the value of some inbound action parameter. Sure. That might look something like this:

 


. . .


 function saveUser()


 {


               // assume we’ve already populated a user object from the html post


               // see the blog entry about using introspection for an example of how to do this easily

 

               $theUser = $this->user; 


 


		// assume form validators are related to business objects


		// get the appropriate validator for inserts and updates


		// often these are the same, but not always - it depends on the 


		// business object 


                // here we’ll use "action" parameter - which may have been the 


                // value of the user form submit button or a hidden field to help figure out 


                // what form validator to use


 


		$validator = null;

		

		if ($this->action == “NEW”)


		{


			$validator = new NewUserFormValidator();


		}


		else


		{


			$validator = new ExistingUserFormValidator();


		}


 


                // in a real system, make sure $validator isn’t null here


 


		if ( $validator->validate() )


		{


			$user->save();


			header(“Location: “ . $successPage);


			return;


		}


		else


		{


                    // since there are errors, let’s get the error list from the validator


                    // and pass that to back to our web form so we can display them


 


		    $errors = $validator->errors;


                    include $editorPage;


		}


 }


. . . 

So that’s it. Looks like a lot of work for such a simple form, huh? I agree - except, that in real world applications, you rarely have just one form, you might have dozens or more - each with dozens of individual form fields. The beauty of this sort of application of the Strategy pattern is that for each new type of field validation task, you simply create a new FieldValidator subclass - and then register the new FieldValidator on the appropriate FormValidator where it’s needed. For example, what if we add email address to our user form? You could easily create an EmailFieldValidator - and then simply add a line to call the addValidator() method in the appriate FormValidator class to use it. What if the field validation rules change as a result of supporting different languages or countries? For example, say you have a need to validate postal codes in the US and Canada. You could simply create US and Canada PostalCodeFieldValidator classes that encapsulate the rules for valid postal formats in those countries. In addition, it would now be pretty easy to add any number of new forms that contain complex validation logic. Need to start writing Contacts or Leads or Invoice details in your web app? Simply create a new FormValidator for each one, and then you business logic will be neatly encapsulated and ready for use as well as extension.

* Note: I talk quite a bit here about abstract superclasses when I discuss the Strategy Pattern. There’s absolutely nothing wrong with using an interface instead. So, if you’re a PHP 5 or Java programmer, and your problem is better suited toward an interface, then by all means, use an interface. Since I’m writing this example in PHP 4 - there really isn’t even any “abstract” nature to these superclasses. Don’t let that put you off - the main point here is to code to a public interface provided by your superclass so you can enjoy the benefits in each concrete implementation.