Qns: Abstract/Interface Class and code reuse

I’ve been thinking how Interface Class can save on coding, since an interface only defines the structure and not the contents of a class (the properties and methods).

interface Application{
public function something();
}

Lets take the above. Any class that implements the Application interface MUST have a something() method. Without an interface, imo, the program still works. That means writing an interface = more code?

I think abstract class is the one that actually saves on code writing since they define the structure and content of a class?

I’m sure I’d missed out some important concept. Else interface classes would not have existed in the first place. Pls help me on what I’m missing here.

You don’t use interfaces for common code.
You use them to link other classes with common functionality.

Example:

  • if class A and B implement your interface, then they must be able to do “something()”, no-matter how they do that “something”, you can be sure that they can do it.

So, in you code, you can have a list of 100 different objects (of different classes), and use them all the same way, without having to check what “type” of object that is, to know what functions to call. (they all have the “something()” function, but might do different things)

Example:

  • basketBall implements Bouncer
  • bowlingBall implements Bouncer

foreach ($balls as $ball) { $ball->bounce(); }

One will bounce, and another one will make a hole in your floor. But you don’t care, they all bounce.

Usually, in TYPED languages like Java you see more usage of the interface (like Typed parameters in PHP)

Hope that helps

PHP and Java are viewes with something of a problem. I don’t but some deem multiple inheritance a problem( a child class is extended of more than 1 parent class in paralell )

eg in PHP it would be


class d extends of b,c

Java used interfaces to solve the diamond problem (http://en.wikipedia.org/wiki/Diamond_problem). Using strictly typed languages or ones like PHP 5 with type hinting the object type in the method declaration designates the contract between the caller and the callee and what public methods will be available. What is deemed publicly available and when is a very serious design issue, passing things by large concrete classes is effectively saying do anything you want to me and the next person who comes along might. Passing things by abstract class reduces this promiscuity but everytime an enlargement is made to it’s public interface for the sake of it’s children these allowances are passed on to things it is passed to.

Now at initial design time when everthing is known abstract classes come in very handy but as a project grows there comes the time when two objects extend of different objects are both needed to be passed to the same processing method. As this method is type hinted a common specification is needed between the two which is where interfaces come in, it is just saying I agree to pass you something with these methods as you method specification says. If the interface specification ever changes it will be specifically for what I want to do so I have perfect right to use them.

Without multiple inheritance/ interfaces the only way to achieve this is to slide in the middle another abstract class( effectively using a template method pattern where not needed )

Eg.


<?php
abstract class AbstractCarDomainSpecificClass{
    
}


abstract class PublicNameInterfaceSpecifyingClass extends AbstractCarDomainSpecificClass {
    
    abstract protected function getNameFromChildClass();
    
    public function getName(){
        return $this->getNameFromChildClass();
    }
}


abstract class PublicClickableInterfaceSpecifyingClass extends PublicNameInterfaceSpecifyingClass {
    
    abstract protected function clickChildClass(); 
    
    public function click(){
        return $this->clickChildClass();
    }
}



class FourWheeledDriveCar extends PublicClickableInterfaceSpecifyingClass{
    
    protected function getNameFromChildClass(){
       return 'FourWheelDriveCarName'; 
    }
    
    protected function clickChildClass(){
        echo "I have been clicked";
    }
}


function ClickProcessor( PublicClickableInterfaceSpecifyingClass $clickable ){
    echo 'ClickProcessor <br/>';
    $clickable->click();
    echo "<br/>" . $clickable->getName(); // The public interface says I am useable due to the inheritance structure so I will use it
}


function NameProcessor( PublicNameInterfaceSpecifyingClass $nameSpecifyingObject ){
    echo '<br/><br/>NameProcessor <br/>';
    echo $nameSpecifyingObject->getName();
}


ClickProcessor( new FourWheeledDriveCar() );
NameProcessor( new FourWheeledDriveCar() );

?>

Now that this might be fine as a solution for now but anything inheriting off FourWheeledDriveCar will be clickable whether it is wanted of not where with interfaces they can be designated at whatever level so they can be passable to processors etc only when it is required. Also due to the inheritance structure their is a permissiveness caused but the ordering of the extension of classes. Change the order and change what is deemed callable as you have changed the contract.

Extending has it’s own problems and is not always the best idea.
PublicNameInterfaceSpecifyingClass in this case is also hard tied to AbstractCarDomainSpecificClass so cannot be used by another class inheritance structure that may want to be passed to the same processor without doing some real hacky stuff.

PHP development environments can make working with them a bit of pig, but in Java IDE’s such as intellij they make coding faster as the ide will happily slap all methods designated by it’s interfaces into the class for you. The extra work really comes from the fact that most environments are at fault for making it hard which is probably why they are not used as much a they should be. In Java tools lazyness entices you to use them, in PHP only self regimentation usually does.

Probably out of all of the basic OOP stuff interfaces are the hardest to get used to as writing things that require interfaces as parameter types require detachment from what is actually being done at that moment as a whole. One minute in this case you are thinking just about car stuff and have to switch to anything stuff.

What becomes more re-usable are the things that require interfaces as they are so generic they can be reused on any project due to the greater portability passing by interface offers. Head first design patterns goes into it but there is too much duck talk in that book for me( they have a duck thing where a lot of examples use ducks as class structures ).

Yep. The point of interfaces is not to write less code.