As I stated before, the sample “dataProcessor” class is in fact a highly generic blueprint, seated on top of the class hierarchy; this comes in useful for creating subclasses that implement a specific functionality. Now that the overall features of any data processor object have been defined, we next need to derive a subclass that provides a concrete implementation for each of the empty methods that you saw previously. Considering this situation, here’s the definition for the “resultProcessor” child class, which as you’ll see, exposes a concrete definition for each method inherited from its parent class. Take a look: // derive 'resultProcessor' class from 'dataProcessor' With reference to the above child class, definitely there are many things worth noting here. Since this class only processes MySQL result sets, the constructor first checks to see whether its incoming parameter $result is really a MySQL result set. The checking code below illustrates this condition: if(get_resource_type($result)!='mysql result'){ After verifying that a real MySQL data set has been passed on as parameter, the class simply assigns it as the only property. Indeed, this is a short and efficient process. Now, let’s move on and pay attention to the next class method, “toString()”, which takes the provided MySQL result set and returns it in a string format, where each row of the data set is delimited by a new line (\n) character: function toString(){ You’ll remember from my schematic “dataProcessor” class, that each method for processing data wasn’t explicitly defined. However, in consonance with the definition of an abstract class, the derived “resultProcessor” class does expose a specific definition for each pertinent method. Now, do you see how child classes implement specifically all the generic methods declared within the base abstract class? I hope you do. In a similar way, the remaining methods, “toArray()” and “toXML()” in question, expose concrete definitions, as you can appreciate from the snippet below: function toArray(){ The subclass that I just created should clarify any questions regarding the appropriate implementation of abstract classes in PHP 4. After all, this isn’t a hard-to-grasp concept. However, to dissipate further doubts, let’s expand the previous example and derive another child class from the “dataProcessor” class, so you can see how the same generic methods you learned earlier are defined in a different way. Curious about how this is done? Right, keep on reading.
blog comments powered by Disqus |