Abstract Classes and Interfaces

[TomTees]

Would someone help me out with Abstract Classes and Interfaces...

 

Some questions...

 

1.) When you have an Interface with Methods, then any Concrete Class that "implements" said Interface must include all of the listed Methods, correct?

 

 

2.) When you have an Abstract Class with Properties & Methods, are you required to use all of the listed Properties & Methods similar to how an Interface works?

 

 

3.) What is the intent of using Abstract Classes vs. Interfaces?

 

 

 

TomTees

 

 

[ignace]

1) Yes.

2) Only if they are declared abstract, everything else is inherited.

3) Only an abstract class allows you to define a body for a method (for example define an interface method)

[TomTees]

>> 2.) When you have an Abstract Class with Properties & Methods, are you required to use all of the listed

>> Properties & Methods similar to how an Interface works?

>

> 2) Only if they are declared abstract, everything else is inherited.

 

So if a Property or Method is not declared "abstract" then you do not have to implement it with an Abstract Class?

 

 

>> 3.) What is the intent of using Abstract Classes vs. Interfaces?

>

> 3) Only an abstract class allows you to define a body for a method (for example define an interface method)

 

So an Interface is just a "contract" that you will implement the listed Methods, but an Abstract Class *can* goes farther and actually spell out what any declared Abstract Methods will entail?

 

 

 

TomTees

 

 

[sharal]

exactly, if a method is declared abstract within the abstract class then the inheriting classes will be forced to implement it, otherwise it works exactly like a normal method being inherited.

 

im sorry if you have read something like this below, but i'll try to explain it anyway, both the interfaces and abstract classes. It's hard to learn when to use abstract classes and interfaces to start off with, but if you are patient your efforts will surely pay off. This is one of the things that you can only learn by coding. Anyway, I hope this is of any help - feel free to question me if you need anymore answers or are in doubt about something, it's quite a large topic if you go into details, but i've tried to sum it up the best I could

 

You should use abstract classes as a design feature when something is actually abstract, an abstract object could be something that is not tangible, a common example is a mammal. A mammal does not define a specific tangible object but is rather a generalisation / abstraction that defines some attributes and actions (methods) that are general for a lot of animals that are mammals (thus they inherit the mammals attributes and actions).

 

Now a mammal is not really a good example is programming, as you will rarely imitate such an object. But basically as there cannot exist a mammal as a concrecte tangible thing - there is no such thing as a mammal, well yes a cat, but not a mammal in that sense. Therefore abstract classes cannot be instantiated, just like there is no such thing as a mammal walking around (literally a mammal, as if it was an unique animal itself).

 

<?php
$abstractClass = new abstractClass; // this will produce an error as abstract classes cannot be instantiated
?>

 

A better example for programming could be a shopProduct. A shopProduct is a rather abstract term as it could basically define any product in your shop, as it does not present anything concrete but rather something that is general, it should be declared abstract. Then you could have tangible objects inheriting from the shopProduct like a bookShopProduct for example, if your shop sold books.

 

As for interfaces:  Interfaces defines a way to implement something, but does not provide the implementation. Instead, as you pointed out, it provides a "contract" that all objects implementing it must abide by. This ensures that you get a common class interface in all classes implementing that interface. So, when you have a class implementing that interface, you know that it will atleast implement those methods that are defined in the interface.

 

An example from the Standard Php Library is the ArrayAccess interface which defines some methods that an object implementing the ArrayAccess interface must implement, in order to make the object act as an array (hence the word "ArrayAccess").  You can see at the php manual here http://dk2.php.net/manual/en/class.arrayaccess.php,

that to implement ArrayAccess into our object, we have to implement the methods (these four methods are the contract, that we must fulfill /implement for our object to act as an array):

 

offsetExists()

offsetGet()

offsetSet()

offsetUnset()

 

in order for our object to be accesible by arrays.

[TomTees]

Thanks for the comments.

 

Okay, but you could view an Abstract Class as a "contract" of sorts as well, because it promises that you will always have certain Properties and/or Methods, right?

 

The difference being - as I understand it - that an Abstract Class would usually not only provide the "contract" of certain Properties and Methods, but the implementation as well (which Interfaces cannot do).

 

Maybe this is an example...

 

abstract class Duck{

private $name;

private $size;

 

public function quack(){

}

}

 

class MallardDuck extends Duck{

private $gender;

 

public function fly(){

}

}

 

class DecoyDuck extends Duck{

private $material;

 

public function float(){

}

}

 

 

 

TomTees

 

 

[sharal]

Yes it does work as a sort of contract too, abstract classes can leave methods that children must implement as well,

then they have to be declared abstract (look below). 

 

And yes, an abstract class can provide both methods with implementations and methods that must be implemented by inheriting child classes.

 

eg:

 

<?php
  abstract class Duck {
    private $name;
   private $size;

    // lets assume that the implementation of how ducks eat food is different, from duck to duck
   public abstract function eat ();

  /* abstract methods within an abstract class does not contain a method body, just like those of an interface, and must be implemented by inheriting children */
}

class MallardDuck extends Duck {
private $gender;

public function fly () {

}

public function eat () {  /* as theres an abstract method in the Duck class that we are extending,
                                         we must implement it in child classes (just like interfaces) */

}
}
?>

 

A little tip on when to use abstract methods:  When you know that something will be different in the inheriting classes, but yet it's a feature that is common.

For instance:  if the MallardDuck and the DecoyDuck both could eat food, but they ate it in different ways (the implementation would differ), then you should have an abstract method in the Duck class named eat(). Doing that, forces MallardDuck, DecoyDuck and all other ducks to implement their own way of eating. The abstract method works as a "contract" again, and it literally defines that all ducks must be able to eat, but they must implement their own way of doing that. Additionally, we can also define in the abstract parent class Duck, that all ducks can Quack, and implement it in the abstract parent class - because all ducks quack the same way, furthermore we can also define properties that are common for all ducks.

 

[sharal]

Btw you might find this interesting:

 

http://www.developer.com/lang/article.php/3628381/The-Object-Oriented-Thought-Process-Index-Page.htm

 

it's a short article of a book named the "object oriented thought process", it explains interfaces, abstract classes and all the basics quite well.

 

http://www.developer.com/design/article.php/3635836/Objects-and-Interfaces.htm

 

 

[ignace]

abstract class Duck{

private $name;

private $size;

 

public function quack(){

}

}

 

class MallardDuck extends Duck{

private $gender;

 

public function fly(){

}

}

 

class DecoyDuck extends Duck{

private $material;

 

public function float(){

}

}

 

This violates the Liskov Substitution Principle as the concrete class is not substitutable for it's parent.

 

function fcukA(Duck $duck) {
    $duck->fly(); // only works with the MallardDuck
}

[sharal]

Well it doesn't  change the behaviour of the parent class, it just extends it. I don't see where you apply the LSP then.

Anyway, you should not ponder things as LSP even though it is vital for making code act as we expect it to, not just yet atleast. Or that depends on how much you can comprehend. The baseclass duck does not implement fly, because the general duck, the abstraction of duck is not able to fly.

[ignace]

Well it doesn't  change the behaviour of the parent class, it just extends it. I don't see where you apply the LSP then.

Anyway, you should not ponder things as LSP even though it is vital for making code act as we expect it to, not just yet atleast. Or that depends on how much you can comprehend. The baseclass duck does not implement fly, because the general duck, the abstraction of duck is not able to fly.

 

Yes which means fly() and float() are obsolete.

 

program to an interface, not an implementation