Question

I have studied in php oop and stocked in the concept of reusable code.

I have seen an example like

interface iTemplate
{
    public function setVariable($name, $var);
    public function getHtml($template);
}
And implement it:

// Implement the interface
class Template implements iTemplate
{
    private $vars = array();

    public function setVariable($name, $var)
    {
        $this->vars[$name] = $var;
    }

    public function getHtml($template)
    {
        foreach($this->vars as $name => $value) {
            $template = str_replace('{' . $name . '}', $value, $template);
        }

        return $template;
    }
} 

I can understand the code but not sure why it is reusable. Every time I want to add a new function in iTemplate interface, my Template class needs to be changed too. I don’t understand the concept of “reuse”. I appreciate any help. Thanks.

Answer 1

Interfaces aren’t directly for code reuse. They are for abstraction. They enable classes that use the template to check for the interface instead of the base template class. That way it separates implementation from the interface declaration.

So if your method does something with a template class, checking for an object of instance template would hard code a dependency on that class. But in reality you don’t care what class you get, you just care if it adheres to the iTemplate interface (since that’s all you’re calling anyway).

public function foo(Template $template) {

vs:

public function foo(iTemplate $template) {

Now, as far as code re-use, interfaces aren’t really designed for that. Inheritance typically is. Basically think of inheritance as extending an abstraction. Let me give you an example:

If you were to create a set of classes for birds, you could approach it with inheritance and without it. Let’s see how we might do it without:

interface iBird {
    public function fly();
    public function speak();
    public function swim();
    public function walk();
}

class Duck implements iBird {
    public function fly() {
        //Fly here
    }
    public function speak() {
        // Quack here
    }
    public function swim() {
        //Swim here
    }
    public function walk() {
        //Walk here
    }
}

class Turkey implements iBird {
    public function fly() {
        //Fly here, but limited
    }
    public function speak() {
        //Make turkey sound here
    }
    public function swim() {
        throw new Exception('Turkeys can not swim!');
    }
    public function walk() {
        //Walk here
    }
}  

Now, this is a simple example, but you can see that in those two birds, the walk() functions will likely be identical (and hence violate DRY)…

Let’s see how that might look with a single tier inheritance:

abstract class Bird implements iBird {
    public function fly() {
        //Fly here
    }
    abstract public function speak();
    public function swim() {
        //Swim here
    }
    public function walk() {
        //Walk here
    }
}

class Duck extends Bird {
    public function speak() {
        //Quack here
    }
} 

class Turkey extends Bird {
    public function speak() {
        //Make turkey sound here
    }
    public function swim() {
        throw new Exception('Turkeys can not swim!');
    }
}  

Now, you can see we just re-used 3 of the methods! We didn’t declare speak(), since it will be always overriden (since no two birds sound alike).

Sounds good right? Well, depending on our needs, we may want to add other abstract types. So lets say we were making a lot of different types of birds… We would have some that didn’t swim, so we might create an abstract class NonSwimmingBird that extends Bird, but throws the exception for us. Or a NonFlyingBird, or a ShortRangeBird…

Now, we’re really on the track as far as code re-use, but we’re hitting a wall in another area. Suppose we have a bird that doesn’t fly or swim. What class do we inherit from? Either way, we’re duplicating code. So we need to find another way out. Well, how do we do it? Through Design Patterns… Instead of direct inheritance, we could use a decorator pattern to add those traits on the fly. (There are other patterns that can be used here, the point is to show that inheritance alone won’t suit all needs. And Patterns alone won’t either. You need a good architecture using both worlds based upon what your exact needs are)…

The point is, it all depends on your needs. If you only have 2 “classes” of objects you’re going to architect something much simpler than if you are planning on having thousands. The point of what I wrote here is to demonstrate how you can use straight inheritance to enforce some DRY principals (but also how straight inheritance can cause code duplication as well). The big thing, is don’t try to stick to DRY just because you don’t want to repeat yourself. Stick to DRY, but make sure that you’re combining and extending where it’s reasonable to, otherwise you’re creating yourself a maintenance headache. Stick to the Single Responsibility Principal, and you should be fine…