Five common PHP Design patterns

Design patterns are just for the Java architect--at least you've probably always thought so. In fact, design patterns are very useful for everyone. If these tools are not patents for "architecture astronauts", what are they? Why are they very useful in PHP applications? This article explains these problems.

Design patterns not only represent a useful way to develop robust software faster, but also provide a way to encapsulate large ideas in friendly terms. For example, you can say that you are writing a loosely coupled messaging system, or you are writing a pattern named Observer.

It is very difficult to demonstrate the value of a schema with a smaller sample. This is often a bit of a overkill, because the pattern actually works in a large code base. This article does not show large applications, so you need to think about how to apply the principle of the example in your own large application-not the code itself, as demonstrated in this article. This is not to say that you should not use patterns in small applications. Many good applications start with small applications and evolve into large applications, so there is no reason not to build on such solid coding practices.

Now that you understand the design patterns and their usefulness, let's look at the five common patterns of PHP5.

Factory mode

Originally in design pattern book, many design patterns encourage the use of loose coupling. To understand this concept, let's talk a little bit about the hard work of many developers working on large systems. When you change a piece of code, there is a problem, and cascading damage may occur in other parts of the system that you thought were completely unrelated.

The problem is tight coupling. Functions and classes in one part of a system are heavily dependent on the behavior and structure of functions and classes in other parts of the system. You need a set of patterns that enable these classes to communicate with each other, but do not want them to be tightly bound together to avoid interlocking.

In large systems, many of the code relies on a few key classes. There may be difficulties when you need to change these classes. For example, suppose you have a User class that is read from a file. You want to change it to another class that is read from the database, but all code references the original class read from the file. At this point, it is convenient to use the Factory mode.

A factory pattern is a class that has some methods for creating objects for you. You can use the factory class to create objects without using new directly. This way, if you want to change the type of object you are creating, simply change the factory. All code that uses the factory is automatically changed.

Listing 1 shows an example of the factory class. The server side of the equation consists of two parts: a database and a set of PHP pages that allow you to add feedback, request feedback lists, and get articles related to specific feedback.

Listing 1. factory1.php

<?php
interface IUser
{
function getName();
}
class User implements IUser
{
public function __construct( $id ) { }

public function getName()
{
return "Jack";
}
}
class UserFactory
{
public static function Create( $id )
{
return new User( $id );
}
}
$uo = UserFactory::Create( 1 );
echo( $uo->getName()."\n" );
?>

The Iuser interface defines what action the user object should perform. The Iuser implementation, called the User,userfactory factory class, creates the Iuser object. This relationship can be represented by the UML in Figure 1.

Figure 1. Factory classes and their associated Iuser interfaces and user classes

If you run this code on the command line using the PHP interpreter, you will get the following result:

The test code requests the User object to the factory and outputs the results of the GetName method.

% php factory1.php
Jack
%