Monthly Archive for May, 2013

Choosing a PHP Design Pattern: Part II—Avoiding Redesign

PickDP2What are the causes of System Redesign?

To get started on Part 2 of choosing a design pattern, we need to look at the causes of redesign. I realize that his is jumping ahead in the list, but because the issue of re-design is at the heart of design patterns, it’s a good place for the second discussion of choosing a design pattern. The Gang of Four point out eight causes, and these causes each have design patterns that will help you avoid this redesign (see pp. 23-25 in GoF.) In this session, we’ll review the eight causes and the suggested patterns that can be used to avoid redesign. Look for the cause of redesign that best fits your system or general type of app.

Creating an object by Specifying a Class Explicitly

In one sense, this cause for redesign can be handled by the what you might do in making a movie deal–

Talk to my agent…

You don’t want to deal with the lawyers, contracts and all the negotiations required to make a movie deal. You just want to read the script, rehearse and get your lines straight. You let Murray (your agent) do all of that for you so you don’t get all tangled up with details you don’t know about or want to know about. Right away, you may be thinking,

That sounds like a Factory…

That’s right! You let the factory deal with the class your client wants to make a request from. A Proxy or Prototype would be another choice for separating request from the class you’re making the request to.

Dependence on specific Operations

Another cause for re-design is a dependence on specific operations which may change. The reason for changing an operation or a set of operations can be anything from a bright idea you get for a better way to set up the operations to changes in the objects the used by the operations. It could also be due to a new operation you want to add to the system. Suppose your system has an operation that handles the request for a phone number. The number could be anything from a land-line phone to a Skype number or something in the future none of us have even though of. You don’t want change in or the addition of a single operation to cause re-design for the whole site. So avoid hard-coded requests and let the decisions be made at compile time or run time. Two examples that avoid tightly bound requests are the Chain of Responsibility and Command patterns.

Dependence on Hardware and Software platforms

If you’re programming on a fairly low level, hardware differences can be more pronounced because you can program directly to the processor. PHP is a server-side language sent to a browser and it doesn’t matter is the user’s system is Linux, Windows and Mac operating systems. So platform is not something we tend to worry about or even have to concern ourselves with—albeit a few exceptions.

Having written design patterns for PHP5+, ActionScript 3.0 and a little Java, I am able to preserve most structures in a cross-language environment. However, I do need to attend to language differences, such as the fact that PHP5+ is weakly typed and ActionScript 3.0 is strongly typed. Gamma and associates suggest the Abstract Factory and Bridge designs to help overcome any software dependencies that may arise. The high level abstraction in both patterns helps to ameliorate any differences in hardware and software. However, most design patterns encourage communication between interfaces rather than concrete implementations, and so I would suggest that most (if not all) design patterns have a healthy regard for cross-platform and cross-API cases.

Dependence on Object Representations or Implementations

<em><strong>Figure 1:</strong>Works like Bait & Switch—as long as the interface is the same, it can make the request</em>

Figure 1: Works like Bait & Switch—as long as the interface is the same, it can make the request

We assume when we build a client class that it will simply make requests. However, to make those requests it has to know how an object is represented, stored, located, and implemented. Rather than having that responsibility thrust upon the client, GoF suggest hiding that information from the client. Then if changes are made, the client can make the same request and the information will be handled through abstract structures where change will not ripple through to the client nor the program. Figure 1 suggests that the Client doesn’t know what it’s getting itself into, and in this case, that’s a good thing! The Abstract Factory and Bridge designs along with Memento and Proxy designs keep request processing information hidden from the client, and so when changes are made, the client can make the same requests but get different implementations representing any changes to the system.
Continue reading ‘Choosing a PHP Design Pattern: Part II—Avoiding Redesign’

PHP CMS Project Part II: Separating Tasks

cms2Separation of Content from Form

In Part I of A PHP CMS Project, you saw how a Web page could be placed in a variable using PHP’s HEREDOC operator. Once in HEREDOC, different parts of the page could be filled with content delivered through variables. Using a simple CSS format, it was possible to have the general layout of a Web page and updates through through a private methods in the same class.

This next step further separates the Web page structure from the data that it uses for content. Essentially, this steps makes the HEREDOC Web page a separate class and calls for content from another class. At this point, there’s no design pattern involved; just a little OOP. In fact everything is the same except the content. (Later on in this series you will see which design patterns would be useful.) Figure 1 shows what the new page looks like:

Figure 1: Content from an external source

Figure 1: Content from an external source

As you can see in Figure 1, the content on the page has changed, but the format is the same. The big difference is that all of the data were sent through an external object. You can test the page and download the source code by clicking the following buttons:
PlayDownload

Once you have downloaded the classes, you can see similarities and differences in the classes now and those in Part I. The first new class to examine is Content. Simply stated, this is the class that stores the data for the Web page. It has a single method, getContent() and no constructor function. As a rule of thumb, if I don’t need a specific constructor function (one using __construct), I don’t include one.


//Content.php
include_once('PageMaster.php');
class Content extends PageMaster
{
    public function getContent()
    {      
        $this->content = array("css" => "heredoc.css",
                         "title" => "Here's Doc!",
                         "header1" => "New York State of Mind",
                         "header2" => "The Travel Page",
                         "body1" => "

Let's go have some fun. This is what I did on my summer vacation. ", "body2" => " There much to see in NYC. Tall buildings, yellow cabs and lots of people.

"
, "image1" => "images/mermaid.png", "image2" => "images/plane.png", "caption1" => "
New York has the best mermaids.
"
, "caption2" => "
Off to New York City.
"
); return $this->content; } } ?>

Now that the content is in a different class, it’s easier to change the content without having to change the DocHere class. Of course the idea is to leave the DocHere class alone and just change the content through the use of variables. However, instead of scalar variables, you can use a compound variable—an array in this case. So now, all of the content has moved from a set of variables in the same class as the HEREDOC Web page to an array in an external class.

Before looking at the updated DocHere class, you will find a small but significant change. Figure 2 shows the difference in how a variable is inserted into a HEREDOC document and how an array element from an external class is inserted into the same HTML tag:

Figure 2: Inserting variables and imported array elements.

Figure 2: Inserting variables and imported array elements.

Note that the same element names (or key names) are used as were for the variable names. (e.g., $this->header1 is now $this->hd[“header1”].) So now, the HTML page is in a single variable ($this->document), and all of the content for that page is in a single array ($this->hd).

To “catch” the data from the Content object, the DocHere class uses the $content variable ($this->content) it inherits from the abstract class PageMaster. Next, the $hd variable (short for ‘html data’) calls the getContent() method from the Content class. The getContent() method delivers the array with the data used in the HTML page.

hd["image2"]}>
  CMSTEMPLATE;echo$this->document;}}?>

//DocHere.php
include_once('PageMaster.php');
include_once('Content.php');
 
class DocHere extends PageMaster
{
    function __construct()
    {
        $this->content=new Content();
        $this->hd = $this->content->getContent();
        $this->document = <<
        
        
        hd["css"]}>
        
        {$this->hd["title"]}
        
        
        

{$this->hd["header1"]}

{$this->hd["header2"]}

{$this->hd["body1"]} {$this->hd["body2"]}
hd["image1"]}>
{$this->hd["caption1"]} {$this->hd["caption2"]}

The business logic if pretty well taken care of in the DocHere and Content classes. So you may well ask, What’s up with the abstract class, PageMaster?

Adding an Abstract Class

At this state of development, the abstract class, PageMaster is nothing more than a placeholder for an abstract class or interface we may need later in the development process. The three variables (or more correctly properties) of the abstract class can be inherited using protected visibility.


//PageMaster.php
abstract Class PageMaster
{
    protected $content; 
    protected $hd;
    protected $document;
}
?>

One OOP principle that you may be able to extract from this is the use of polymorphism. The $content object is used in both implemented classes. In the Content class, the $content property is an array, while that same property name in the DocHere class is an instance of the Content object. It’s not the best example of polymorphism, but it’s a start. (You can see more typical and useful examples of polymorphism in abstract methods—with properties the polymorphism is almost the same as the difference between the same local variable name used in different functions.) Further, keep in mind that that actual array from the Content object is stored in the $hd array; not the $content object in the DocHere class. It is passed to $hd using the following:

$this->hd = $this-content->getContent())

So for now, don’t worry about the PageMaster abstract class. However, in future development, of both the abstract class and the CMS project, you may find it quite important.

Why The Baby Steps?

Some readers may wonder why this example is taking its sweet time working up to both a CMS and design pattern in PHP. In reference to the book (PHP Design Patterns, some readers have complained that it is too difficult to understand. Despite the fact that it was written for advanced PHP developers, there’s no getting around the fact that design patterns are hard to learn. (Even the authors of the original Design Patterns book say that design design patterns and OOP are hard to comprehend, and their audience consists of C++ and Java developers!) With a plethora of bad examples of design patterns in PHP that are easy to understand on the internet, I thought working slowly through the logic of some examples on this blog may come up with both a good design pattern example and make it both practical and comprehensible. Any reader feedback on this topic will be quite helpful and welcomed.

A PHP CMS Project: Part I

cmsWeb Pages in Classes

One of the more difficult styles of programming for me that most PHP programmers use is mixing in HTML and PHP. It certainly gets the job done, and for most that’s all that counts. However, with certain types of projects, mixing HTML is difficult to maintain and re-use. So, I thought that a good starting point for making a CMS is using a HEREDOC string inside a class. Once the basic structure is in place, data could be updated using external data without having to change the basic structure of a Web page or re-writing the HTML. Figure 1 shows the final results of an HTML page created with a PHP class. The “external data” at this point is “stored” in a class method. The page is very simple based on a typical Web page with headers, body text and captioned images. Figure 1 shows the results:

Figure 1: Page with data added

Figure 1: Page with data added

To get an idea of how to use this, and see it live on a Web page use these buttons to play it and download the files:
PlayDownload

(Depending on what you’re using to view this page, the two images are going to be more or less distanced from one another in the browser. You can jiggle the CSS to make any adjustments you want, but I just re-sized the browser. Likewise, the two header fonts may need some adjustment as well since I downloaded two non-standard art deco fonts.)

HEREDOC: A Web Page in a String in a Class

The first thing I did was to use PHP’s HEREDOC syntax. (You can find out about using HEREDOC in the manual.) I’ve come to reference HEREDOC in all caps since after the <<< operator the HEREDOC name is in all caps. Essentially, this approach places the entire Web page in a string. You have to be careful when using HEREDOC to place the closing HEREDOC name on the far left of the script with nothing more than a semi-colon after it.

You may be thinking that such an approach is very limiting because the entire Web page is contained within a single string. However, the Web page in the HEREDOC string is actually a template for what you may want to add. Just like using an external link to get your CSS, all of the content for the page is from external sources. In this initial example, the “external” source is simple a private method (getContent()) within the DocHere class as can be seen in the following listing:

image2>
  CMSTEMPLATE;echo$this->document;}   privatefunction getContent(){$this->css="heredoc.css";$this->title="Here's Doc!";$this->header1="The Main Section";$this->header2="This is a Section Header";$this->body1="

Here is whatever has to be said, thought, discussed or just chatter."; $this->body1 .= " You can tell the reader as much or as little as you like.

"
;$this->image1="images/rose.png";$this->caption1="
Lady with flowers and the moon.
"
;$this->image2="images/poland.png";$this->caption2="
I really want to visit Poland.
"
;   }}?>
//DocHere.php

class DocHere
{
    private $document;
    private $css;
    private $title;
    private $header1;
    private $header2;
    private $header3;
    private $body1;
    private $image1;
    private $image2;
    private $caption1;
    private $caption2;
 
    function __construct()
    {
        $this->getContent();
        $this->document = <<
        
        
        css>
        
        $this->title
        
        
        

$this->header1

$this->header2

$this->body1
image1>
$this->caption1 $this->caption2

In looking at the class, think of it in three parts:

  1. Set of variables declared for use in the Web page
  2. The HEREDOC string containing the Web page template
  3. Content for the page

By placing all of the variables in a private visibility, you can quickly and easily encapsulate data that actually goes into the Web page. The variables provide a clear outline of what is available to change in the page. Keeping in mind that his is a Web page to be updated with external data, the private visibility helps to limit what kind of external data gets to be on the page. (It must be assigned to a private variable through some kind of public access.)

The HEREDOC string just makes it easy to drop in a Web page without a lot of string concatenation. In fact, you can create and test a standard HTML page and copy and paste it into the HEREDOC variable ($document.) Just remember to replace the content with the set of private variables.

Finally, the getContent() method is just a place-holder for whatever kind of data resource you want to use. As we develop this into a useful CMS application, we will want to keep in mind the decomposition process where we keep all of the parts separate and simple.

Finishing Touches

Before finishing up this first part, take a look at an external data source used in the program: the CSS file.

@charset "UTF-8";
/* heredoc.css */
/* CSS Document */
/*468966,FFF0A5,FFB03B,B64926,8E2800 */
body {
        background-color: #FFF0A5;
        color: #8E2800;
        font-family: Georgia, "Times New Roman", Times, serif;
}
h1 {
        font-family: "Raconteur NF", futura, fantasy;
        background-color: #468966;
        color: #FFB03B;
        text-align: center;
}
h2 {
        font-family: NITECLUB, fantasy;
        color: #468966;
}
.pixcaption {
        font-style: italic;
        font-size: 11px;
        color: #B64926;
}
.doRight {
        float: right;
        padding-left: 10px;
}
.doLeft {
        float: left;
        padding-right: 10px;
}

As noted, the CSS style sheet is simple, and you may want to make adjustments to your own taste or requirements in an external style sheet. If you use jQuery tools in your HTML pages, you will find that they can fit in the current format quite easily.

A little trigger script launches the DocHere object (class):


//calldoc.php
include_once('DocHere.php');
$worker = new DocHere();
?>

The external trigger script is a temporary stand-in for a Client class to be developed later for making specific requests. Be sure to place the calldoc.php file in the same directory as the DocHere.php file.

External Data Options

In developing a CMS, even a simple one such as the one in this series of posts, you need to begin thinking about how data are to be updated. In the next installment in this series, we’ll try out some externally supplied data and start thinking about what kind of design pattern would help to maintain a Web site through a PHP CMS.

Choosing a PHP Design Pattern: Part I—Selection Criteria

PickDP Which Design Pattern?

One of the most persistent questions that I get is, How do you select a Design Pattern?, and usually, my response is, Decide what varies and see which pattern handles that variation. Of course, you will find that lots of things vary, and deciding which one to build a design pattern around can be tricky. Furthermore, GoF have lots more to say about how to go about choosing a design pattern than just encapsulating variation. This series will cover the different criteria so that we can get a complete picture of the selection process.

Gamma, Helm, Johnson and Vlissides (aka Gang of Four) provide six criteria for making a selection (pp.28-30). They include:

  • Consider how design patterns solve design problems
  • Scan Intent sections
  • Study how patterns interrelate
  • Study patterns of like purpose
  • Examine a cause of redesign
  • Consider what should be variable in your design

Many of the selection solutions that GoF offer are simply references to a part of their book that discusses what design patterns do (which you may not have yet read), and so I’m going to try and summarize each of these criteria. That may result in an oversimplification, and you’re welcome to point out any such misstep I make and set me straight if you believe that a summarized explanation is too terse. (Better yet, go over pp. 11-31 and read all of the detail yourself.)

Consider how design patterns solve design problems

Section 1.6 (pp. 11-28) of Design Patterns is laden with major concepts and information about design pattern use as a strategy for solving design problems in programming. The foundation in finding an appropriate object is the idea that,

objects package both data and procedures that operate on data, and the only way that an object performs an operation is when it receives a request from a client.

Implied in that idea is that an objects’s internal states are encapsulated. You know what that is, and so we can move on to the central OOP issue of decomposing a system into objects. How do you do that? It’s not easy because you have so many factors to consider (some of which may be conflicting) in the decomposition process.

Figure 1: Breaking down complexity into simple parts

Figure 1: Breaking down complexity into simple parts

So what is the decomposition process? Basically, it’s breaking down a complex problem down into smaller, more manageable units—in the case of PHP design patterns, classes, (objects). At the root of all English literature is the alphabet. (See Figure 1) The degree to which you decompose a task refers to its granularity. Breaking down the works of Shakespeare can have different levels of granularity. For example all of Shakespeare’s works can be broken down into plays, plays into acts, acts into scenes, scenes into paragraphs, paragraphs into sentences, sentences into words, and finally words into letters of the alphabet. The degree of granularity depends on what you need. Understanding the alphabet will not help you understand much about Shakespeare, but if you don’t know the alphabet, you cannot read his plays, sonnets and poems. (See Object Granularity below).

Beginning with the problem (e.g., How to make a sniffer, how to create a UI for an online store, how securely store and retrieve data), you have to decide the way in which you want to break it down. (It’s not going to break itself down!) The only thing that has ever worked for me is knowing exactly what I want to do. In other words, you need some serious understanding of the problem itself. So even before you begin to work through the decomposition process, you need to study the project you want to complete. The OOP process for decomposition has different approaches:

  • Write a problem statement and create classes and operations from nouns and verbs in the statement.
  • Focus on the collaborations and responsibilities in the system (problem you’re trying to solve).
  • Model the real world and translate the objects found during analysis into design.

At one time or another, I’ve used all of these approaches, and they all work. Usually, I find myself going between them, combining them—shaking the box with the problem inside to see how things settle at the bottom. However, it’s difficult to provide a generic case, and so I’ll provide two cases that I actually worked through.
Continue reading ‘Choosing a PHP Design Pattern: Part I—Selection Criteria’