|
Friday, 28 July 2006 |
In object oriented programming, object creation - also known as instantiation - is an implied requirement. Objects must at some point be created for use. Obviously, creating objects is not a difficult task and most languages, PHP included, have simple and intuitive syntax for doing so.
When developing larger, more complex systems though, object creation can become difficult. There are situations where different objects may need to be created based on different conditions or based on the context of the object creating it. Creating objects of concrete types explicitly in code can make these situations a nightmare when it comes time to make revisions and additions. When a new class is introduced, you get to follow a trail of code and commence the hours of debugging that will inevitably follow such an endeavor. This is where design patterns come in.
The Factory Method pattern defines an interface for object creation but defers the actual instantiation to subclasses. Take, for example, an application that processes Electronic Funds Transfers (ETFs). There are numerous types of ETFs including virtual check, credit card, wire transfer and so on. Using a non-pattern based approach, the application code requesting an ETF object would need to know precisely what subclass of ETF is needed, and it would need to know the context in which that type of ETF is requested. We would end up with code looking something like this:
|
|
Read more...
|
|
|
Friday, 28 July 2006 |
The Singleton is one of the simplest Patterns to understand. Its common usage is to ensure that only one instance of a class is ever instantiated. The reason for wanting such behavior varies but typically it is because only one object instantiated from the source class is required and you want the resulting object to be available throughout an application, i.e. globally available.
An example might be a class for storing Settings. A Settings class is a good candidate for a Singleton because its data is immutable (the only way to change settings data is to edit the settings file) and it is likely required in many areas of an application. Furthermore creating a new Settings object wherever it is needed is wasteful of resources - each is identical to all others.
|
|
Read more...
|
|
|
Friday, 28 July 2006 |
PHP has a history of using functions for iterating, but there is now a push to use objects in PHP 5. The Iterator pattern is not language specific and doesn’t need any language enhancements to create. The only added benefit however is the usage in foreach loops with the SPL Iterator interface, but more on that later.
The Iterator Pattern allows for accessing the current element and allowing the retrieval of additional elements in a loop routine or manually in a code block. The Iterator pattern is not constraining to the class for which it holds the data. An object can also aggregate the iterator from outside its class providing iteration while also keeping from implementing the iterator as part of the object. Aggregation of the iterator is a better practice for optimizing overhead for developers who won’t use the main class for implementing the main Iterator methods.
The iteration in classes is not as simple as collecting all of the data and passing it off to the developer. This action doesn’t take in consideration the many data sources that could be used to gather the data in the first place. Including the initial iteration to collect and append the data to the array, which is not a optimal practice. With the Iterator pattern, you should only collect the information, as you need it for when it needs to be passed to save memory.
The Iterator pattern allows you to control how the iteration operates. It makes the iteration go smoothly and easier for the developer as the method names are standard for each Iterator object and won’t need to reference a manual. A developer would be able to take any iteration and know that what method to call.
|
|
Read more...
|
|
|
Design Patterns 
