Validating Incoming Data: Putting the Validators To Work - PHP

As one might expect, putting the earlier validators in action is an extremely simple process, reduced to creating a few instances of them and calling …yes, their “validate()” method. To demonstrate how to accomplish this, below I wrote a basic script which uses the pertinent validators to check some sample input data (to keep things shorter and clearer, I haven’t implemented an autoloader, but you can do that if you want to).

Here’s the script:

<?php

require_once __DIR__ . '/Helper/ValidatorInterface.php';
require_once __DIR__ . '/Helper/AbstractValidator.php';
require_once __DIR__ . '/Helper/UrlValidator.php';
require_once __DIR__ . '/Helper/EmailValidator.php';
require_once __DIR__ . '/Helper/FloatValidator.php';
require_once __DIR__ . '/Helper/IntegerValidator.php';

use Library\Helper\UrlValidator as UrlValidator,
    Library\Helper\EmailValidator as EmailValidator,
    Library\Helper\FloatValidator as FloatValidator,
    Library\Helper\IntegerValidator as IntegerValidator;

// create instances of the validators
$urlValidator = new UrlValidator('http://www.devshed.com');  
$emailValidator = new EmailValidator('user@domain.com');
$floatValidator = new FloatValidator(2.5);
$intValidator = new IntegerValidator(10.5);

// validate a URL
if (!$urlValidator->validate()) {
    echo $urlValidator->getErrorMessage();
}

// validate an email address  
if (!$emailValidator->validate()) {
    echo $emailValidator->getErrorMessage();
}

// validate a float number
if (!$floatValidator->validate()) {
    echo $floatValidator->getErrorMessage();
}

// validate an integer number
if (!$intValidator->validate()) {
    echo $intValidator->getErrorMessage();
}

/* displays the following

The supplied value is an invalid integer number.

*/

While this brand new example is somewhat trivial, it shows how easy it is to utilize the functionality of the previous validators to determine the validity of some incoming data. In this case, client code consumes instances of them directly to perform the process of checking. It’s possible, though, to inject them into other objects (a composite implementation would be a typical situation), or something like that.

Of course, the most relevant detail to notice here is that now we’re working with actual objects, and not simply with procedural code encapsulated within a bunch of static methods. This change itself makes it really worth all the work required to create the originating validator classes and the interface that they implement.

To sum up: even in the simplest use cases (like the one shown above), be sure to build non-static classes. In doing so, you’ll be able to enjoy all of the goodies provided by object-oriented programming, which will translate into more robust and reliable code.

Final Thoughts

Over the course of this two-part tutorial, I showed from a practical standpoint why the use of static helper classes (in this case, a trivial “catch-all” validator) can be detrimental to building robust and scalable object-oriented applications in PHP (you should remember that the concept is language agnostic). In addition, I implemented a set of instantiable, fine-grained validators, which can be easily tested in isolation, injected into the internals of other objects, and so forth.

Even though all of these examples were rather contrived, they made my point about the drawbacks of using purely static classes. In light of this, the next time you get your hands dirty writing your own helpers (or any other class, of course), bear in mind that you’re making your best programs by doing good object-oriented design, which is not class-based. The difference is subtle, but important.

See you in the next PHP development tutorial!