PHP Objects, Patterns, and Practice- P4

PHP Objects, Patterns, and Practice- P4: 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- P4 CHAPTER 7 ■ WHAT ARE DESIGN PATTERNS? WHY USE THEM?PHP and Design PatternsThere is little in this chapter that is specific to PHP, which is characteristic of our topic to some extent.Many patterns apply to many object-capable languages with few or no implementation issues. This is not always the case, of course. Some enterprise patterns work well in languages in which anapplication process continues to run between server requests. PHP does not work that way. A new scriptexecution is kicked off for every request. This means that some patterns need to be treated with morecare. Front Controller, for example, often requires some serious initialization time. This is fine when theinitialization takes place once at application startup but more of an issue when it must take place forevery request. That is not to say that we can’t use the pattern; I have deployed it with very good results inthe past. We must simply ensure that we take account of PHP-related issues when we discuss thepattern. PHP forms the context for all the patterns that this book examines. I referred to object-capable languages earlier in this section. You can code in PHP without definingany classes at all (although with PEAR’s continuing development you will probably manipulate objectsto some extent). Although this book focuses almost entirely on object-oriented solutions toprogramming problems, it is not a broadside in an advocacy war. Patterns and PHP can be a powerfulmix, and they form the core of this book; they can, however, coexist quite happily with more traditionalapproaches. PEAR is an excellent testament to this. PEAR packages use design patterns elegantly. Theytend to be object-oriented in nature. This makes them more, not less, useful in procedural projects.Because PEAR packages are self-enclosed and hide their complexity behind clean interfaces, they areeasy to stitch into any kind of project.SummaryIn this chapter, I introduced design patterns, showed you their structure (using the Gang of Four form),and suggested some reasons why you might want to use design patterns in your scripts.It is important to remember that design patterns are not snap-on solutions that can be combined likecomponents to build a project. They are suggested approaches to common problems. These solutions 129 CHAPTER 7 ■ WHAT ARE DESIGN PATTERNS? WHY USE THEM?130CHAPTER 8■■■Some Pattern PrinciplesAlthough design patterns simply describe solutions to problems, they tend to emphasize solutions thatpromote reusability and flexibility. To achieve this, they manifest some key object-oriented designprinciples. We will encounter some of them in this chapter and in more detail throughout the rest of thebook. This chapter will cover • Composition: How to use object aggregation to achieve greater flexibility than you could with inheritance alone • Decoupling: How to reduce dependency between elements in a system • The power of the interface: Patterns and polymorphism • Pattern categories: The types of pattern that this book will coverThe Pattern RevelationI first started working with objects in the Java language. As you might expect, it took a while before someconcepts clicked. When it did happen, though, it happened very fast, almost with the force of revelation.The elegance of inheritance and encapsulation bowled me over. I could sense that this was a differentway of defining and building systems. I got polymorphism, working with a type and switchingimplementations at runtime. All the books on my desk at the time focused on language features and the very many APIs availableto the Java programmer. Beyond a brief definition of polymorphism, there was little attempt to examinedesign strategies. Language features alone do not engender object-oriented design. Although my projects fulfilledtheir functional requirements, the kind of design that inheritance, encapsulation, and polymorphismhad seemed to offer continued to elude me. My inheritance hierarchies grew wider and deeper as I attempted to build new classes for everyeventuality. The structure of my systems made it hard to convey messages from one tier to anotherwithout giving intermediate classes too much awareness of their surroundings, binding them into theapplication and making them unusable in new contexts. It wasn’t until I discovered Design Patterns, otherwise known as the Gang of Four book, that Irealized I had missed an entire design dimension. By that time, I had already discovered some of thecore patterns for myself, but others contributed to a new way of thinking. I discovered that I had overprivileg ...