PHP Objects, Patterns, and Practice- P5

PHP Objects, Patterns, and Practice- P5: This book takes you beyond the PHP basics to the enterprise development practices used by professional programmers. Updated for PHP 5.3 with new sections on closures, namespaces, and continuous integration, this edition will teach you about object features such as abstract classes, reflection, interfaces, and error handling. You’ll also discover object tools to help you learn more about your classes, objects, and methods.
Nội dung trích xuất từ tài liệu:
PHP Objects, Patterns, and Practice- P5 CHAPTER 10 ■ PATTERNS FOR FLEXIBLE OBJECT PROGRAMMINGand queries transparent to the client. Trees are easy to traverse (as we shall see in the next chapter). It iseasy to add new component types to Composite structures. On the downside, Composites rely on the similarity of their parts. As soon as we introduce complexrules as to which composite object can hold which set of components, our code can become hard tomanage. Composites do not lend themselves well to storage in relational databases but are well suited toXML persistence.The Decorator PatternWhile the Composite pattern helps us to create a flexible representation of aggregated components, theDecorator pattern uses a similar structure to help us to modify the functionality of concretecomponents. Once again, the key to this pattern lies in the importance of composition at runtime.Inheritance is a neat way of building on characteristics laid down by a parent class. This neatness canlead you to hard-code variation into your inheritance hierarchies, often causing inflexibility.The ProblemBuilding all your functionality into an inheritance structure can result in an explosion of classes in asystem. Even worse, as you try to apply similar modifications to different branches of your inheritancetree, you are likely to see duplication emerge. Let’s return to our game. Here, I define a Tile class and a derived type:abstract class Tile { abstract function getWealthFactor();}class Plains extends Tile { private $wealthfactor = 2; function getWealthFactor() { return $this->wealthfactor; }} I define a Tile class. This represents a square on which my units might be found. Each tile hascertain characteristics. In this example, I have defined a getWealthFactor() method that affects therevenue a particular square might generate if owned by a player. As you can see, Plains objects have awealth factor of 2. Obviously, tiles manage other data. They might also hold a reference to imageinformation so that the board could be drawn. Once again, I’ll keep things simple here. I need to modify the behavior of the Plains object to handle the effects of natural resources andhuman abuse. I wish to model the occurrence of diamonds on the landscape, and the damage caused bypollution. One approach might be to inherit from the Plains object:class DiamondPlains extends Plains { function getWealthFactor() { return parent::getWealthFactor() + 2; }}class PollutedPlains extends Plains { function getWealthFactor() { return parent::getWealthFactor() - 4; }} 179 CHAPTER 10 ■ PATTERNS FOR FLEXIBLE OBJECT PROGRAMMING I can now acquire a polluted tile very easily: $tile = new PollutedPlains(); print $tile->getWealthFactor(); You can see the class diagram for this example in Figure 10–3. Figure 10–3. Building variation into an inheritance tree This structure is obviously inflexible. I can get plains with diamonds. I can get polluted plains. But can I get them both? Clearly not, unless I am willing to perpetrate the horror that is PollutedDiamondPlains. This situation can only get worse when I introduce the Forest class, which can also have diamonds and pollution. This is an extreme example, of course, but the point is made. Relying entirely on inheritance to define your functionality can lead to a multiplicity of classes and a tendency toward duplication. Let’s take a more commonplace example at this point. Serious web applications often have to perform a range of actions on a request before a task is initiated to form a response. You might need to authenticate the user, for example, and to log the request. Perhaps you should process the request to build a data structure from raw input. Finally, you must perform your core processing. You are presented with the same problem. You can extend the functionality of a base ProcessRequest class with additional processing in a derived LogRequest class, in a StructureRequest class, and in an AuthenticateRequest class. You can see this class hierarchy in Figure 10–4.180 CHAPTER 10 ■ PATTERNS FOR FLEXIBLE OBJECT PROGRAMMINGFigure 10–4. More hard-coded variations What happens, though, when you need to perform logging and authentication but not datapreparation? Do you create a LogAndAuthenticateProcessor class? Clearly, it is time to find a moreflexible solution.ImplementationRather than use only inheritance to solve the problem of varying functionality, the Deco ...