Balanced Braces

     A long time ago there was a young upstart programmer who believed firmly in coding standards and the DRY principle. He was in a dev team which, for the most part was fairly productive, despite their manager. One day the dev team met with their seasoned manager who was deeply imbued with the lead-last form of leadership and well versed in the art of stifling progress, as a good seasoned manager should be.

     One day the upstart programmer disagreed with the seasoned manager on the topic of database normalization. The upstart programmer, seeing that the database was unnecessarily repeating too much of the same data, in various tables, wanted to apply DRY principles by adopting at least the first normal form, otherwise known as 1NF.

     Upon hearing the upstart’s argument, the seasoned manager responded with,

“Young upstart, you may read a lot of books, but out in the real world, out on the street, we do things differently.”

     Thus began the legend of the Street Programmer.

     You see, the seasoned manager had real world experience, and in his world, real-world programmers (the type that programmed from the street) simply didn’t have time to read books, or catch up on latest technologies. No, in fact, if they didn’t agree with the purpose of a new concept, they burrowed themselves deeper into their comfortable leather chairs and dismissed all comers for lack of experience.

     The seasoned manager, being a Street Programmer himself, went on to talk down the use of hashed and encoded passwords, the uselessness of Object Oriented Programming, and spoke lovingly of the use of REGISTER GLOBALS in PHP. This was not a man to be trifled with, he was a man of the street, and he knew his business.

     The upstart programmer, having seen the error of his ways, turned his face downward and exited the conference room where the Street Programmer reigned supreme, and subsequently got a new job that though lacking in a sufficient amount of Street Programmers, was still able to make do. The Street Programmer’s company had other ideas, he was able to sell it to marketing types who bought into the depth of his Street Programming knowledge, and he walked away a happy man.

These two are new to PHP5 and are part of a new set of features that greatly improves OOP in PHP. At first glance abstract classes and interfaces look very similar but they have key differences. I’ll briefly introduce both and then lay out the significant differences.

Abstract Classes
An abstract class is created as a parent class which can be used when extended. Instead of saying:

class messages
{
}

you would do this instead…

abstract class messages
{
}

In an abstract class, you can define properties and methods as you would normally with any class. The kicker is that you can add ‘abstract’ in front of your methods to just define that they are required in the child class and then the child class expands on those definitions. Kind of like a header file in C. Here’s an example:

abstract class messages
{
    var $msg;

    abstract public function showMessage();
    public function cleanMessage()

    public function setMessage($msg)
    {
        $this->msg = $msg;
    }
}

Interfaces on the other hand, also allow you to define a “header” of sorts so that you define what properties and methods should be in any class that uses it BUT it doesn’t allow you to expand on it. Here’s an example:

interface messages
{
    var $msg;

    public function showMessage();
    public function cleanMessage()
    public function setMessage($msg);
}

From there, you can then start building a class that “implements” that interface and build out the actual guts of what the interface defines:

class myMessage implements messages
{
    var $msg = 'Default Message';

    public function showMessage()
    {
        // ....
    }
    public function cleanMessage()
    {
        // ....
    }
    public function setMessage($msg);
    {
        // ....
    }
}

Interfaces are great when you want to provide a kind of API that other classes must follow. Also, a class can implement multiple interfaces whereas you can only extend one abstract class. You can do this by separating each interface with a comma . . .

class myMessage implements messages, communication
{
    //.....
}

This is where the creative parts of a programmers brain must kick in . . . when do you use an abstract class and when does an interface make sense? This all depends on what the needs of your application are. Consider the differences between abstract classes and interfaces. And if that wasn’t enough to get your brain going . . . when is it best to just use a simple parent class vs. an abstract class.

I’d say keep these things in mind:

• use a simple parent class when the child objects will share common properties and methods but then have a vast variety of it’s own properties & methods
• use an abstract class when the child objects will both share common properties and methods but also have similar functionality that they perform in different ways
• use interfaces when you simply want to define a rigid ‘API’ that the classes must follow

But all applications vary so you must do what will work best for your application.

And lastly . . . don’t spend a large chunk of your development time debating between these little intricacies. Speed is a competitive advantage. Make your choice and follow through with it.