Design Patterns for PHP

Design patters are needed for architect-ing large and good maintainable projects. It helps in developing software correctly and speedily.

When I read these design patterns I thought that these design pattern are not very useful. Still after reading some of the design patterns in short many of them was good in propagating ideas. We need terms for communicating complex theory in IT industry. By telling this I am not telling knowing the name of design patters is sufficient for architecting a software product. This subject is for advance level. Deciding which pattern to use and how to mix when this is required will be very complex task.

This article is just written more as a critical point of view and not for seriously learning the Design Patterns. It is written after I read few design patterns for the first time and I was not interested to learn more of it. :)

Here are five design patters discussed in this design pattern article.

Singleton Pattern:

This helps in maintaining resource creation. Sometimes you want only one and one object at a time related to a resource.
In the aforementioned article example is based on Database but you know PHP + Mysql automatically manage mysql connection. When there is already a open connection then use it otherwise they create a new one. Yes, there is some doubt about closing the connection after use. Then you have option of register_shutdown_function().

After knowing singleton pattern, it is so beautiful to communicate that I want singleton pattern for this resource instead of telling all the details.


Factory Patterns:

This looks me only indirection. If you read this article you will find that the situation discussed in the article can easily be managed if you develop you code around data. Instead of just returning database or file handle, which many developers do, you can return the desired content in a structure. If name and age is required from there, return those from the structure. After changing your code from file read to database read you could return the data in same format, so, no need to worry about the calling module/code.

This discussed about the concept coupling. This is very desired for good software. I saw this concept is very badly handled in many software design. Are you surprised! Programmer instead of developing loose coupled and modular code they develop fragmented code and write lots of extra code, where if you want to change something, you will find locating the culprit code and tracing the flow of the process will become very harder than developing a whole new system. Problem is software job cannot be handled by doing clerical kind of job. Very hard fact!

The Observer Pattern

As the name suggest there will be one observer component and one observable component. After reading the code and UML there, you many find the concept very complex. Concept is simple. It is one observer and one observable. You may have used variable or database table where you store some value based on one process and started new process based on that stored value. Is it not right! Or I missed the concept. May be! I am new in this design pattern field.

The chain of command patterns

Name tells that is must be a complex process. Yes developing this kind of system can be daunting task. Where you put more than one commander at various places and your data passed through those places and commander do their work on the data, without data being dependent on those commander. Here data can be a message, command, request or something else. Handle can be added or removed without disturbing or influencing other handlers.

The strategy Pattern

This pattern seems unsuitable for this place. According to the role of the patterns discussed here, its should be named something else and this should not be in pattern. Anyway role it is handling is very good for ensuring the quality and managing the maintainability of the software product.