PHP design patterns

Some programmers and teachers like to promote design patterns to improve code reliability. Frameworks replace design patterns in the commercial world. Content management systems replace frameworks in most new projects. Do design patterns have a place in modern programming? Do Java based design patterns help or damage PHP based Web development? Here is the future based on real experience.

Job prospects

Job descriptions do not mention design patterns, they mention frameworks, content management systems, and degrees. Programmers looking for programming roles will look at the challenging jobs involving PHP and databases, jobs which often request experience with Cake, Symfony, Zend, or one of the other frameworks. People with an artistic flair will most likely end up working with a content management system producing themes.

Some jobs require a degree and the person hiring the graduate might prefer a graduate from the same university. Graduates of Sydney University look for graduates from Sydney University. I sat in a meeting where a large number of middle level managers bragged about graduating from Sydney University. We were going around the table introducing ourselves. There were three of us in the group who had not graduated from Sydney University and one was looking like the victim of school yard bullies. How could I interrupt the preening and bullying? I had visited Cambridge, if only for coffee and a walk along the river. Fortunately the first non Sydney University graduate was a lady who said Harvard. The bragging stopped. (The lady graduated somewhere else.)

Your degree type and source are more important than any design patterns you learnt while attending classes.

Patterns or frameworks

Some development frameworks classify their code classes based on patterns. PHP is so flexible that there are high speed functions to perform some of the things described in patterns without creating special classes. It is sometimes useful to classify classes by patterns but not useful to change classes to fit artificial definitions of patterns.

The really important things within a framework are consistency to make the framework easy to learn and best use of the programming language, which may mean code and patterns different from Java where most of the patterns are originally described. PHP has natural data and list processing built it. There is rarely a need to slow down an application with junk code inserted purely to emulate an approach used in Java. The approach used in Java is used in Java purely because Java is missing so many basic data related features.

Frameworks provide greater productivity increases than patterns. In fact patterns do not provide any productivity increase, patterns are really only a documentation tool. If you define a class as a singleton, future programmers know it should have only one collection of values based on a unique identifier and will not try to add other items. I remember a case where a contact class was modified to have multiple addresses. There was already an address class but the new programmer ignored the address class and added address information to the contact class. There had to be at least two addresses, one for home and one for work. What the programmer should have done, and might have done if the programmer followed design patterns and the contact class was documented as a singleton, was to put the person related information into a person class then use the contact class to group together a person and a list of addresses. The person and address classes would be singletons and the contact would become something else.

The patterns

• Data transfer object or DTO or Value object
• Factory
• Singleton

Some other patterns include Active record, Adapter, Data mapper, Decorator, Iterator, Mock object, Model-View-Controller, Observer, Proxy, Registry, Specification, Strategy, and Table data gateway.

Data transfer object

The Data transfer object, or dto, used to be called a value object and was only needed for the Java programming language because the Java programming language lacks data storage. PHP has genuine native data storage, a far more efficient and flexible approach.

If you want to invent a dto for PHP, you could create a dto for dates because dates can be used in a lot of different formats and a date object could provide that compatibility. The instant you add date format conversion to your date dto, the dto is no longer a dto, it becomes a Singleton or some other design pattern.

When you store data in PHP lists, arrays, you can use lots of high speed searches and other efficient techniques on the data. If you replace each data item with a dto, you have to create slow inefficient code to find and work with the data. That horrible artificial code is one reason why some activities in some PHP frameworks can be as slow as Java.

The Web has ignored dtos for data transfer. There are lots of standards in place for data transfer and none of the commonly used standards uses dtos. Java dto creators add extensions to their dtos to let the dtos be serialised for transfer through the standards that do not waste time on dtos. The instant you add data serialisation to a dto, the dto is no longer a dto.

Factory

A Factory pattern class or object creates objects. That seems useless in PHP where object creation is so easy. The real use is in code where you combine already loaded data. You might be creating an address object. Someone selects a country and your code creates a country object. The person selects a city from the list for that country and your code creates a city object. Next the person enters address information and your code creates an address object. The address object contains a postcode formatted for the country and selected based on the city. If you create a factory class to create the address object, the factory can use the country and city objects to create an address object with some data customised for they country and city.

You would only use a factory class if there is something unique you can add to the created object based on known data at the time of creation. You could only use a factory where you create a lot of objects with the same input. Factories fail when people try to build in lots of business logic to create different objects with unrelated data.

As an example, I created a framework that included a country class and a factory for creating objects that used the country information. In effect all the factory did was create the object from the class then use a method to set a link to the country object. I have worked on projects where the factory is then expanded to do many different things and maintenance is almost impossible. Instead, for the framework, I built factories that used other factories. Most data related objects were created by a database related factory that added in common database processing links. The country factory called the database factory to create a database related object then the country factory added in the country information and returned the object. The contact factory called the country factory to get contact objects customised by country. There were other factories using factories. Each factory did one unique thing, could be maintained independently from the other factories, and could be tested without running the whole application.

Singleton

The Singleton is a Data transfer object with additional code. The code is for validation or to create compatibility.

The name Singleton indicates there is one value or item stored in the object. The item might be a compound value or a collection of data with a single relationship but not a list.

An example compound value is a telephone number with an area code. The area code is kept separate from the number because in some circumstances you do not dial the area code. The combination of area code and number represents a single telephone number and is a singleton.

An example of a collection of data with a single relationship that is a singleton is a row from a database. The row might be a contact entry containing an address and the telephone number at that address. There is just one contact and it is a singleton.

An example of a collection of data with a single relationship that is not a singleton is a list of the telephone numbers within an area code. Their one relationship is the area code. The list is not a singleton.

Conclusion

Use patterns to help classify your existing code, not to artificially restrict it to emulating the slow difficult bits of Java.