The tandem composed of the Composite and Decorator design patterns offers an example that shows where the use of Composition can help in building flexible applications. While decorators are normally used for extending the functionality of objects that are of the same type without having to appeal to Inheritance, Composites provide an elegant and efficient paradigm that allows programmers to manipulate single objects and collections of them through the same interface. There’s a plethora of situations where Decorators are utilized successfully in the development of PHP-based programs, and more specifically in the construction of versatile user interfaces on web pages. But what about Composites? Well, there's a relative of Composite called “Composite View,” which can be used for rendering single and multiple (X)HTML templates in a very flexible fashion. Simply put, client code consuming a composite view class will be able to manipulate web page sections, and even entire (X)HTML documents, via the same set of methods without being aware of this. That’s a good example of encapsulation, right? If you've already read previous parts of the series, then you've seen a couple of concrete ways to implement the Composite View pattern. I started by creating a simple hierarchy of composite view classes, comprised of an abstract parent that defined the structure and behavior of generic view objects. I then created a concrete subclass, which was responsible for handling these objects individually and collectively via a unique rendering method. To complete this hierarchy, though, it’s necessary to create an additional class. It will be tasked with creating single view objects. So, in this third installment of this series I’m going to show you how to build such a class, which will be an approachable process, believe me. Now, it’s time to get rid of the dull theory and continue exploring the benefits of using the Composite View pattern in PHP. Let’s go! Review: a quick summary of the sample classes developed so far Just in case you still haven’t read the tutorial that precedes this one, where I showed how to create a concrete composite view class derived from the abstract parent mentioned in the introduction, below I included for you the definitions corresponding to these sample classes. This way, you can quickly grasp how they work. First, here is the abstract parent, which is tasked with modeling the structure and behavior of generic view objects: (AbstractView.php)
abstract class AbstractView // constructor // get the specified property from the view // remove the specified property from the view
<?php class ViewException extends Exception{} If you study the above “AbstractView” class in detail, you’ll realize that it’s nothing but a simple container that stores the properties assigned to a generic view object, including its associated template file. Of course, its “render()” method is responsible for rendering the template, but only for a single object. However, a typical implementation of a Composite View should be able to render single and multiple templates through the same interface. How can this be done? Well, the following concrete subclass performs this task in a fairly straightforward fashion. Look at it, please: (View.php)
class View extends AbstractView There you have it. As you saw before, the previous “View” class is capable of rendering indiscriminately a single template or a collection of them, thanks to the implementation of the inherited “addView()” and “removeView()” methods. Even though at first glance, a composite view class like the one defined above seems to be pretty pointless, the truth is that its functionality can be cleverly exploited to render multiple web page sections and complete (X)HTML documents via a single method call. But in fact I’m getting ahead of myself, since the full details of how to accomplish this will be covered in upcoming parts of this series. For the moment, the next thing we must do is create a concrete implementation of the previous “AbstractView” class that allows us to create single view objects in a truly painless way. Precisely this process will be discussed in the next section, so to learn more about it, click on the link below and keep reading.
blog comments powered by Disqus |
|
|
|
|
|
|
|