As I said previously, having a result set decorator class which behaves like a bridge between the original class and further ones makes constructing new decorator classes a simple process. To demonstrate the veracity of my concepts, I’ll begin creating some simple decorator classes, where each of them is tasked with taking a MySQL result set and returning it in a different format. The list of these new classes starts with the “StringResultDecorator” class, which has been defined as follows: class StringResultDecorator extends ResultDecorator{ Did you think that building another decorator class was really harder? Not at all! As you can see, the above class accepts an object of type “ResultDecorator” and returns a completely formatted result set, via its “displayString()” method. In this case, I used only a “<br />” tag for modeling the respective dataset, but this might be entirely modified to include more complex tag formatting. As shown above, implementing the decorator pattern allowed me to add more functionality to the original “Result” class, without having to change its initial structure. Indeed, this is a very cool and handy concept. Now, let me show you how to create a couple of additional decorator classes, which are capable of returning MySQL result sets, both as XML data and arrays respectively. The definitions of these classes are listed below, therefore please examine their source code: // define 'ArrayResultDecorator' class As you’ll surely realize with reference to the above classes, they’re very similar to the previous one. In this case, both of them also take an object of type “ResultDecorator” and return differently-formatted result sets by their “displayXML()” and “getArray()” method respectively. What makes these classes really interesting is their capability to expand the functionality of the original “Result” class without having to modify its signature. This is what I would call a good example of the decorator pattern in action! Well, now that you know how all the decorator classes look, it’s time to put them to work, so you can have a better idea of how they fit into the potential context of a Web application. For this reason, below I’ve set up an example which shows how to use each class separately. Please have a look: try{ In the above example, first I established a connection to MySQL, then fetched a result set from a hypothetical “USERS” database table, and finally returned it as a formatted string, by using the “displayString()” method. Short and simple, right? Now, suppose you want to return the same MySQL result set, but this time as XML data. The below script does precisely that: try{ And lastly, the example ends by showing how to return the result set in question as an array structure: try{ All right, as you saw, returning MySQL result sets in different formats without changing the initial definition of the pertinent “Result” class is a no-brainer process, considering the correct implementation of the decorator pattern in PHP. Of course, I should mention that the same result might be obtained with inheritance, but as I stated before, there are times when you need to work with objects of different types. Final thoughts Sad but true, our journey surrounding the creation of decorator classes has ended. I hope that all the practical examples that you learned here will serve as a good introduction for understanding the development and application of decorator objects in PHP even better. See you in the next PHP tutorial!
blog comments powered by Disqus |
|
|
|
|
|
|
|