Monthly Archive for June, 2010

PHP Proxy Design Pattern: Protect Your Assets

Published on June 5, 2010 by Bill Sanders in Proxy. 4 Comments

Protection Proxy Design Pattern

The Proxy Design Pattern is another pattern that’s easy to understand. Essentially, you have a proxy object that acts as a stand-in for a real object. A request is made to the Proxy which in turn passes on the request to the RealSubject or blocks the request from the RealSubject. The purpose of the Proxy is to have variation where you have different ways an object is accessed. As a result, you find the Proxy patterns are commonly found where you have login controlled by a username and password. The access, while it may appear to be directly to the object of interest, is actually through a proxy object.

Try it out clicking the Play button and the Download button will download all of the files. (To figure out the username and password see the Proxy.php file listing.)

The Many Faces of Proxy

The Proxy design pattern has more than one kind. All Proxy designs separate the request from the RealSubject, but because of the different applications, Gamma, Helm, Johnson and Vlissides (p. 210) specify three distinct kinds of proxies:

  1. Remote Proxy. When a proxy object is in one address space and the real object is in another, the proxy is a remote one. Besides using a remote proxy as a firewall, the remote proxy can be used for online games where the same object is needed in different places at the same time.
  2. Virtual Proxy. A virtual proxy may cache information about a real subject so that access to the real subject can be postponed. Sometimes high security logins use a virtual proxy for the login before the real object handles the login data.
  3. Protection Proxy. The protection proxy keeps the request away from the real subject until the request is verified by the protection proxy. The real subject is the target of the request, such as access to database information. Many protection proxies have different levels of access, depending on the user’s login information; so instead of having a single real subject, the real subject may be multiple and restricted.

    Figure 1 shows the proxy’s structure that can be applied to all three kinds of proxies:

    Figure 1: Proxy Design Pattern

    The RealSubject and Proxy classes share the same interface (Subject) whether it is an abstract class or interface. Note that the request is through the Subject interface, and with PHP, that can be a little tricky, but as you’ll see, not impossible.

    Ask the Proxy

    To understand the Proxy design pattern In a nutshell,

    The client makes a request through the proxy and the proxy passes on the request to the real subject.

    Often, you will see an object diagram that outlines the structure of the pattern at run-time. Figure 2 shows the Proxy pattern in such a diagram:

    Figure 2: Proxy Object Diagram

    As you can see, the client holds a reference to the Subject and the Proxy holds a reference to the RealSubject. In designing an application in PHP, we need to keep in mind that the reference to an interface requires use of PHP type hinting. That is a crucial requirement because programming to an interface instead of an implementation is one of the key requirements of using design patterns correctly. The interfaces provide the loose coupling in a design pattern.
    Continue reading ‘PHP Proxy Design Pattern: Protect Your Assets’

PHP Factory Method Design Pattern : Decoupling Your Products

Published on June 1, 2010 by Bill Sanders in Factory Method. 0 Comments

Let the Factory Build Your Products

One of the easiest design patterns to both understand and create is the Factory Method. However, the Gang of Four provide more than a single basic structure for the pattern and do not specify exactly where the Client makes its request. As a result, one may not recognize one implementation or another. Generally, I assume that requests from the Client class are made directly through the Creator class. However, some implementations suggest that the Client holds a reference to both the Creator and Product (GoF, 110). For this example I chose to use a parameterized version. In this version of the Factory Method pattern, the factory method is allowed to create multiple kinds of products. As noted by GoF,

The factory method takes a parameter that identifies the kind of object to create. All objects the factory method creates will share the Product interface.(pp. 110-111).

This approach calls for an abstract class that can handle a wide variety of concrete products. At the same time, though, we want it to be useful as well. For this example, the Product class has an abstract method to generate the concrete product (getData), but it also holds the properties with the connection values for the MySQL server. So this allows the developer to change the contents of the concrete products without having to even think about the connection values. (This assumes that the same connection information is used by all of the products.) Figure 1 shows the class diagram for this kind of Factory Method implementation.

Figure 1: Parameterized Factory Method Class Diagram

The Client’s role is implied to hold references to the Creator class (factory) and the Product class. The Product reference is through a parameter in the Creator instance. Because the the Creator interface holds a Product as its parameter in the form of a type hint, the request from the Client is to the abstract Product class and not the concrete product declared in the ConcreteCreator parameter. As a result, it’s easy to add more concrete products without having to re-write the whole program. You can just add the new concrete product class with the appropriate interfaces and call them with the Client referencing the concrete product as a parameter of the ConcreteCreator instance. For instance, the following lines shows such a request:

$this->graphicGetter=new ConcreteCreator();
print($this->graphicGetter->factoryMethod(new GraphicProduct()));

The same instance could be called again for a TextProduct. Therein lies the beauty of programming to the interface instead of the implementation. You can test the program and download the files by clicking the buttons below.

Note: When you look at the code in the downloaded files or in the listings, I used the MySQL settings from my localhost on my computer. Obviously, you will want to substitute those settings for your own; so be sure to get your own MySQL user, password, databases and tables set up before trying to run the files. Also, the project stemmed from a Dreamweaver PHP group whose names were substituted by known and unknown blues, boogie and jazz artists. Make changes in those elements to suit your tastes.

To better understand the actual program, click below to go to the steps in building the application:

Continue reading ‘PHP Factory Method Design Pattern : Decoupling Your Products’