Monthly Archive for February, 2013

I Was a PHP Programmer with 1 Year Experience 20 Times

Published on February 19, 2013 by Bill Sanders in Introduction to Design Patterns and OOP and Design Pattern Principles. 4 Comments

OneYear20Lots of Wrong Experience

A number of years ago I was doing research on juvenile gang violence.* Over a period of about 12 years I went out with a police gang unit and gathered data on gang-related violence. During that time, personal computers were coming into vogue, and I thought that it might be a good idea to set up a database for the gangs so that the gang unit could help prevent gang violence and solve cases of gang violence. The cops in the gang unit liked the idea because they could have a database that pin-pointed the kind of crime they were tasked with preventing and investigating. The more general police department computer ran on a VAX and while they had a decent database, it was more for administrative goals than investigative ones, and the investigative elements were far too general to be of much use to the gang unit.

During the discussion with the head of the gang unit, one cop came up and said, “I’ve got over 20 years experience dealing with these punks, and they only thing they understand is a thump on the head.” His comment was duly noted, and after he left, the head of the gang unit turned to me and said,

He doesn’t have 20 years experience. He’s got 1 year experience 20 times.

He was telling me that after his first year, this guy never bothered to learn anything new; he just kept recycling the old knowledge.

A PHP Programmer with 1 Year Experience 20 Times

Over the years that I’ve been programming, I’ve learned new languages and new techniques in languages as they developed. Like most others, I started with sequential programming and quickly graduated to procedural programming. However, I got stuck with procedural programming and for the next 20 (or so…) years that’s what I did. I programmed in several different languages, but other than an experimental flourish in OOP, I just cranked away with my old habits that I had learned when I first started programming. However, in 2005 while doing some work for another programmer, Jonathan Kaye, who has a PhD in computer science from University of Pennsylvania, I was introduced to State Machines. Now State Machines (or Finite State Machines), require a different approach to programming. Using statecharts was a lot different than those old flow charts (that I never used anyway), and I had my first epiphany in looking at a program from a wholly different perspective. From State Machines, I found the State design pattern, and very quickly I found myself immersed in OOP.

I had been like that cop who had 1 year experience 20 times. Not only did I know a lot of languages, but I was advanced in several. However, I was not advanced in my thinking about programming. I was back doing procedural programming that I had learned my first year of programming.

A Trip to the 10th Floor

Once I got going, it was not an incremental climb.

It was like taking an express elevator from the basement to the 10th floor.

An insight here, a class there, and before I knew it, I was able to think OOP. I didn’t plan it. It just happened. Now the route I took was not with any language I was comfortable in. I was comfortable in and using ActionScript 3.0, PHP, JavaScript and coming along with ASP.NET/C#. Of course I knew BASIC from the old days, but I had switched from using VB to C#; so I wasn’t actively using BASIC at all in any form. Head First Design Patterns had just been published and the authors took the time to work their way through examples explaining problems developers would have as new requirements were added and changes made to an existing program. All of the examples were in Java, and I had to translate them into ActionScript 3.0 and PHP. It was not easy, but it had the added benefit of having to pay attention to the reasoning behind design patterns and not just copying and pasting code. The authors had advanced degrees (one a Ph.D and the other, a Masters) in computer science from Yale University; so I had no fear that they didn’t know what they were talking about. (That can be a problem…)

Anyway, the process was liberating. Instead of getting 1 year experience 20 more times, I was getting new experiences and finally growing as a programmer. Now, when I look at a programming problem, I look at it differently than I did for the first 20 years….and from the 10th floor.

I would be very interested in hearing any of your experiences. Use the comment section to relate your PHP experiences with OOP structures and the pros and cons of OOP approaches to PHP programming.

*(I really did gang research for over a decade. .)

Bedrock Strategy Pattern: The Family of Algorithms

Published on February 6, 2013 by Bill Sanders in Introduction to Design Patterns, OOP and Design Pattern Principles and Strategy. 0 Comments Tags: , .

AlgorithmFamilyOrganizing Algorithms

Working through Larry Ullman’s PHP Advanced and Object-Oriented Programming (3rd Ed) book with the Boston PHP Percolator group, we came to an example of the Strategy pattern, and I decided to re-write it. I was able to preserve Larry’s sort algorithms, but I took a different tact for the rest of the pattern. One of my favorite features of the Strategy pattern is that the Gang of Four note that it removes the need for conditional statements. Oh boy! No conditional statements!

You may well wonder why not having conditional statements is a good thing. Simple. Without conditional statements in a program, it’s easier to update and change it. If you’ve ever written a big program and you make changes, you have to go through all of the conditional statements and make sure that needed changes have not upset the coding apple cart. (The State design pattern is another one that has no conditional statements.) This does not mean that design patterns are anti-conditonal statements, but they can get in the way when making changes and updates. Besides, only the Strategy and State patterns are mentioned as having the advantage of no conditional statements. The client makes a request, and the pattern goes straight to requested property or operation with no if’s or switches. After all, if a client wants an algorithm, why should it have to go through a conditional series if it knows what it wants? (If the client is not sure what it needs, a Chain of Responsibility pattern, that does have conditional statements, is used. However, all the conditionals are pretty much the same and just check to see if the request has to be passed along the chain.) To get started take a look at the generated output and download the files:
PlayDownload

Context class and Strategy interface

Larry Ullman’s idea of using different sort algorithms is a perfect example of a “family of algorithms.” So when creating this particular Strategy pattern, I kept the same algorithms, but I removed the conditionals from the concrete strategies. To get started you can take a look at the formal class diagram in the first PHP Strategy pattern placed on this blog. After taking a look at it, consider Figure 1 that shows the general files used and their relationship to one another:

Figure 1: File Diagram of Strategy Pattern

Figure 1: File Diagram of Strategy Pattern

We begin with the Context class. It has three features (GoF 317):

  1. It is configured with a ConcreteStrategy object.
  2. It maintains a reference to a Strategy object.
  3. It may define an interface that lets Strategy access its data.

First, look at the following Context class. The first thing to note is that it is not an abstract class nor an interface. See if you can recognize the three elements the the Context participant listed above:

?View Code PHP 
< ?php
class Context 
{
    private $strategy;
 
    public function __construct(IStrategy $strategy) 
        {
        $this->strategy = $strategy;
    }
 
    public function algorithm(Array $elements) 
        {
        $this->strategy->algorithm($elements);
    }
}
?>

You can see that the constructor function calls for a ConcreteStrategy. We know that because the type hinting shows that the data type must be IStrategy. Looking ahead, you find that IStrategy is an interface; not a concrete class so you may think, “That’s wrong!” However, PHP type hinting allows the data type to be a child of the named type. (The same is true for strongly typed languages like C# and Java as well.) Further, a principle of design patterns is to program to the interface and not the implementation. Besides, you cannot create an instance of an interface or abstract class anyway, so the type would have to be a concrete implementation of the interface (IStrategy, which is the Strategy participant in this example).

Second, it maintains a reference to the Strategy object (IStrategy in the example). The private variable $strategy is assigned a Strategy instance. Again we know that because the type hinting requires an IStrategy type.

Third, the class defines an interface that gives Strategy access to its data in the algorithm() method. Note that the $strategy property is part of algorithm() method that has been instantiated through the IStrategy type hinted argument passed in constructor.

The Strategy participant in the design pattern is an interface, IStrategy. It is nothing more than a method expecting an array as an argument. The individual concrete strategy classes instantiate the method in any way they want, as long as the argument is an array.

?View Code PHP 
< ?php
interface IStrategy 
{
    public function algorithm(Array $elements);
}
?>

Think of the algorithm() method as a way for the Strategy to access the data.
Continue reading ‘Bedrock Strategy Pattern: The Family of Algorithms’