As you learned in the previous section, building a MySQL result processing class capable of accepting a visitor object is in fact a straightforward process. Nevertheless, the structure of the visitor class itself hasn't been defined yet. Thus, considering this condition, it's very convenient to start modeling its general signature.

But how will this be done? That's a simple question to answer. First I'll define an abstract visitor class, and then I'll derive a subclass from it, which will implement concretely the corresponding methods.

Therefore, here is the base abstract class that defines the general structure of visitor objects:

// define abstract 'Visitor' class
abstract class Visitor{
    abstract function visitMySQLResult(Result $resultObj);
}

As you can appreciate, the above abstract class has only one relevant method, that is "visitMySQLResult()", which defines the generic behavior of the class in question. However, it should be noticed how this method accepts an object of type "Result" as its unique incoming argument, in order to do its business.

Since the previous "Visitor" base class shouldn't present big difficulties with understanding its structure, now let me show you the respective subclass that will be provided with the concrete ability to inspect MySQL result sets. Please, take a look at the signature of this new child class:

// define subclass 'MySQLResultVisitor'
class MySQLResultVisitor extends Visitor{
    private $resultObj;
    public function visitMySQLResult(Result $resultObj){
        return $resultObj->countRows();
    }
}

Now you'll have to agree with me that the previous sub class is highly comprehensive. After all, its whole functionality is based simply on taking a result object as incoming parameter, and returning the number of rows present in the record set by using its "countRows()" method. True to form, this visitor in particular isn't very demanding with reference to its visited objects, but it shows in a clear fashion how the visitor pattern can be applied in this specific situation. This isn't rocket science at all!

Fine, at this stage you hopefully learned how a MySQL processing class can be coded in such a way that it can accept a visitor object. In addition, you also saw how the proper visitor class was defined. So, the question that comes now is: what's the next step?

Well, as I expressed right at the beginning of this article, my intention was to create a visitor object which will be capable of establishing an interaction between several MySQL result sets and a PHP-based pagination system. Based on that prerequisite, in the following section I'll create a comprehensive pagination class which will use a single visitor object to paginate the pertinent MySQL data sets.

To find out how this process will be done, please click on the link below and keep reading.