Constructors are often used to shortcut dependency injection and parameter passing on instantiation. This is a valid practice and often leads to shorter code. Consider the following example (a simple value object, often used to not mess around with floats and to keep currency and amount together) ...
PHP V5's object-oriented features give you the ability to implement design patterns to improve your code's design. When you improve your code's design in this way, it becomes more readable, more maintainable, and more robust to absorb changes.
Originally, I planned to write about how to configure the Apache server to run both PHP4 and PHP5. With the push toward PHP5 (see Go PHP5), there are now hundreds of articles covering that topic. Instead, I will talk about two IT patterns I use for PHP development on Windows. The patterns are ancient and familiar to most Unix developers, but little used in the Windows world.
Since the patterns existed long before the term "design patterns" came into vogue, they don't have any names that I am aware of. In this article, I will call them the Bait-and Switch and the Shell Game patterns.
If you need to create multiple objects that belong to the same family, you probably want to use the factory pattern. This three-part series takes a close look at using the factory pattern in PHP.
The composite pattern is one of the less commonly used patterns in PHP 5. Nevertheless, in certain situations, it is very helpful. This article, the first one in a two-part series, will introduce you to the basic concepts of the composite pattern.
The strategy design pattern is applied much more often than you might think, so if you want to find out how to implement it with PHP 5, this article should guide you through the whole learning process. Welcome to the final installment of the series that began with “Introducing the Strategy Pattern.” In two parts, this series walks you through the key points of how the strategy pattern works, and accompanies its theoretical concepts with copious hands-on examples.
The strategy design pattern can be very useful in the context of form validation. This article, the first of two parts, will introduce you to the strategy pattern and give you some idea of how you can use it in your own PHP applications.
Whether you’re a PHP developer who has been using this useful server-side scripting language for a while, or a seasoned programmer who has spent many years developing PHP-driven web applications, it’s highly probable that you have already used (deliberately or not) a design pattern.
While this isn’t a fact that is going to change the way you create your PHP programs permanently, the truth is that there are certain design patterns that are much more common to implement during the development of specific web applications than others.
Naturally, this concept may sound strange at first, particularly if you’re just starting to dig deeper into the huge and fascinating terrain of PHP-based programming, but consider this: how many times have you used the "new" PHP keyword to create an instance of a particular class? Or, more to the point, how many times have you utilized the "&" operator to avoid working with multiple instances of that class?
Probably the answer to the above questions is tens or hundreds of times, right? In these cases you used a basic implementation of the Factory and Singleton patterns respectively, maybe without being aware of it.
As you can see, there are certain design patterns that are more usually applied than others. That’s exactly the case with the subject of this article, the strategy pattern. To put things more clearly, I’m sure that you always validate adequately all the forms included in your web sites. First off, you create a few validation functions (or classes), then use these functions to check the validity of the data supplied by users, and finally determine the course of action to be taken accordingly.
In the example that I described above, you first selected a context where the corresponding form validation was going to take place, and then applied a data checking strategy to establish programmatically how different types of user inputs will be verified.
Certainly, this is a concrete implementation of the strategy design pattern, in a situation that should be familiar to you! In other words, when this pattern is applied, there will be a predefined context (in object-based programming this is represented by a context class) that will be capable of selecting what type of action must be taken, in accordance with the requirement of a specific strategy (again, in OOP this is achieved by coding different extensions of a class interface).
Now that you know at least in theory how the strategy pattern works, in this two-part series I’m going to demonstrate the practical side of this topic. I will provide you with some illustrative examples that hopefully will help you understand how the pattern can be included in your own PHP applications.
Ready to face this challenge? All right, let’s go!
If you’ve been anxiously awaiting part two of this series then your wait is over. Here’s a short introduction to the section part of this series written by the author of the book, Dagfinn Reiersol. I had the privilege of meeting Dagfinn at phpuk last week. Below the introduction is the link I know you’ve been waiting for.
In this section we’ll learn about two patterns: Decorators and Null Objects.
A Decorator is another kind of wrapper around a class. It is used to add responsibilities to a class without burdening the class with additional methods.
A Null Object is an object that participates in the design like an ordinary object, but doesn’t actually do anything. It keeps the OO machinery working smoothly with no
special handling of cases in which nothing needs to be done.
Among the considerable variety of structural design patterns that can be implemented with PHP 4 (and PHP 5, by the way), there’s one in particular that deserves special attention. It's easy to apply in the context of a given web application, and it offers remarkable functionality when it comes to preventing the unnecessary instantiation of different classes. This two-part series covers that pattern.
Naturally, if you already read the title of this series, then you’ll know that I’m speaking specifically of the flyweight pattern. But before I go into further explanations, let me tell you briefly how this pattern works. This will give you a better idea of how and when it can be used.
In simple terms, when the flyweight pattern is applied, it’s possible to specify programmatically that a particular class is going to have only a predefined number of instances, which are shared within the same implementation. This simple concept itself introduces an immediate benefit: it prevents unnecessary instantiations of the class in question across the same application, which results in a noticeable improvement in the performance of certain systems that must work with heavy loads.
Certainly, if you reread the above definition, it’s clear to see that a flyweight class can be considered a straightforward approach to keep the creation of objects carefully balanced. This can improve the web server’s overall performance, as I mentioned a few lines above.
Nonetheless, this series isn’t limited to introducing boring theory on how the flyweight pattern works. You'll have the chance to learn and test many practical examples related to the referenced pattern, so you can quickly start applying it in your own PHP applications.
A final note before I proceed further: all the examples that you’ll see here will be developed with PHP 5, but they can be easily modified to work with PHP4 as well.
Having clarified that point, let’s find out together how to implement flyweight classes with PHP. It’s going to be instructive and fun!
To keep programming productive and enjoyable, state-of-the-art practices and principles are essential. Object-oriented programming and design help manage complexity by keeping components cleanly separated. Unit testing helps prevent endless, exhausting debugging sessions. Refactoring keeps code supple and readable. PHP offers all this…and more.
The book is written by Dagfinn Reiersol with Marcus Baker and Chris Shiflett.
News von
