The Importance of Well Designed Code

The Anti-Pattern

Spaghetti code, big balls of mud, and copy-and-paste programming. We've all seen it (and probably done it) before, and it ain't pretty.

So what do you do when you need to fend off God objects, infinitely intertwined GOTOs¹, highly-coupled code, or other anti-patterns? Design patterns to the rescue!

The Design Pattern

Design patterns serve as reference describing how to solve recurring problems in application design and software engineering. What you get is not a finished design or even completed code, but rather a handy template that can be adapted and reused in many different situations. In other words, a bunch of really smart people came up with solutions to a bunch of really common problems so that we would have the luxury of not having to recreate the wheel from scratch a bunch of times. By standing on the shoulders of giants, we can produce efficient, logical, and reusable code quickly and easily while avoiding many of the pitfalls that are common in the software industry.

Design patterns owe their beginning to Austrian architect Christopher Alexander, whose book Notes on the Synthesis of Form was required reading for computer science students in the '60s. His work is largely based on the theory that end-users are a more valuable resource for architecture (software design) than any architect (software engineer) could ever be.

A further rise in popularity of Design patterns can be attributed to the book Design Patterns: Elements of Reusable Object-Oriented Software, published by The Gang of Four in 1994.

Real World Example: The Singleton Pattern

We use the Singleton pattern frequently in our work. For instance, once a user is logged into a website, the application is responsible for remembering their information while they move around and interact with the site. The best way to do this is with a Singleton class:

class user extends model {
    private static $thisUser;
    
    public static function thisUser() {
        if(self::$thisUser != null) {
            return self::$thisUser;
        }
        else {
            if($obj = self::find($_SESSION['user_id'])) {
                self::$thisUser = $obj;
                return self::$thisUser;
            }
        }
        
        return false;
    }
}

This (simplified) bit of code checks to see if the object representing the current user has already been defined. If so, it simply returns that object.

If not, it uses a static method called find() (inherited from the base model class) to locate the row in the database that corresponds to the user, using the primary key stored in the session. Upon successful creation of the user object, it stores the object back into the static instance variable for later use.

In the rare event that something goes terribly wrong along the way, the method returns false to alert the calling class of the error.

The utility of the Singleton pattern in this instance (pun intended) is that it saves server resources by only requiring one database call and one memory allocation on any page that needs to know information about the user. Additionally, storing the user object in the user class itself and keeping its access level as private helps keep the application code clean and organized.

As with anything in the development realm, a little bit of a learning curve is involved in order to understand the best way to implement design patterns. After all, overuse or misuse of design patterns is another anti-pattern in and of itself!