Jump to content

Abstract classes vs interface


terryds

Recommended Posts

abstract classes is a way that you can be less specific about using a taxonomy of objects, cutting down on a lot of if/else code, yet without sacrificing the identity of what those classes really are. lets say you have a program that determines the reaction your pet's have to your actions. if you give your pet some attention, if it was a cat it would purr, or if it was a dog it would wag it's tail. well we can abstract this reaction out to be less reliant on the type of pet and simply call the abstract class's "happy()" function. at compile time the code will have no idea what type of pet is "happy", but when the program is running it will know in context.

abstract class Pet{    abstract protected function happy();    abstract protected function angry();    abstract protected function isSpoiled();}class Dog extends Pet{    public function happy(){      return "*wagging tail*";    }    public function angry(){      return "*grrrrrrr*";    }    public function isSpoiled(){      return false;    }} class Cat extends Pet{     public function happy(){       return "*purrs*";     }     public function angry(){       return "*hiss*";     }    public function isSpoiled(){      return true;    }}

so then in the application it doesn't always need to know exactly what the object is... just that its "some pet". In real life, you wouldn't always fully refer to your pet, for example, like "Spot, my dog which is a border-collie, is happy". Usually you would simply say "spot is happy". and others would know you're referring to your border-collie since you told them the first time, and not everytime.

$spotty = new Cat;$gaveAttention = false;$isFed = false;if($gaveAttention){    echo $spotty->happy();}else if ($spotty->spoiled()){    echo $spotty->angry();}if($isFed)    echo $spotty->happy();

now if you want to change that for a Dog, you only have to change ONE line. or if you add in a new pet type, like a goldfish. then it won't break your previous code. when I'm using the class, i don't have to be specific about the pet. To me, your cat has been abstracted to a generic "pet" and I let the inherited concrete classes (Dog, Cat, and soon Goldfish) worry about the specific details. The less a section of code needs to know about another section, the easier it it to expand that code's functionality without breaking something "else". For example you can further add a multitude of other pet types like snakes and parrots (even a pet rock) and it won't break the initial code. since the running code doesn't rely on a specific pet type, just the abstract Pet class. This is probably the most common way abstract classes are used but not the only way. instead of abstracting objects, one can instead abstract algorithms for dynamic behavior at runtime.

 

for instance if you have a pizza making program, that can make a variety of different pizzas. every pizza has their ingredients gathered, they are then baked, and then served. but not every pizza has the same ingredients (cheese, pepperoni, supreme?), and isn't baked in the same way (soft or crispy crust?), and could be served differently (pickup, delivery, or home-made?). so you can always call the prepare(),bake(), and serve() functions (every pizza will always call those functions and in that order) but what those functions actually make in the end depend on the concrete class you use (home-made, soft crust, cheese pizza).

Edited by Hadien
  • Like 2
Link to comment
Share on other sites

What if i use interface?

 

 

<?phpinterface Pet{protected function happy();protected function angry();protected function isSpoiled();}

 

And then, i implement the dog class and the cat class....

So, what's the difference between interface and abstract class ?

Link to comment
Share on other sites

interface is sorta different. interfaces are more of an abstraction of behavior, rather than an abstraction of objects/data, like abstract classes are. An interface is not specific to an object's taxonomy. rather completely different objects can share the same behavior. to get back at my pet example. say a parrot was added to the abstraction. now a parrot can fly, and flying isn't particularly a unique feature to Pets in general, plus a parrot isn't the ONLY thing that can fly. you can make an airplane object. Airplanes can fly... but they aren't pets, and they are definitely not Parrots, but both Parrots and Airplanes can use similar code to implement flying.

 

lets say you make moveable interface class with a move() function. then you make a walking, swimming, and flying class that 'extends' (not implements) moveable class. now you add a movePet function to the Pet abstract class. the Cats and Dogs classes will "implement" the walking class for their movePet() function, goldfish will use swimming, and parrot will use flying. and in the end code you just call movePet() and the code will polymorphically use the right behavior for each pet. You can't (more like shouldn't) code it the other way around, you don't create a flyable interface, and then have a bunch of objects that can fly (airplanes, helicopters, parrots) extend it.

 

Think of abstract classes as an "is-a" relationship, and an interface as a "can" relationship. a dog "is-a" Pet, and dogs "can" walk. but dogs (or Pets for that matter) aren't the only things which "can" walk.

 

you can take my pet example and turn the happy() and angry() functions into interfaces, since all sorts of things could be happy or angry, not just pets. heck even my pizza example has great use of interface (and abstraction).

 

EDIT:

since my Pet class example was all behavior, you could technically make it into an interface in of itself. but then I would rename it from Pet to Emotion so that it makes more sense, when you would write Dog/Cat/Parrot implements Emotion and a Person implements Emotion, but a Airplane/Helicopter/Rock wouldn't implement Emotion.

Edited by Hadien
  • Like 2
Link to comment
Share on other sites

Abstract classes allow you to add a default constructor, properties and methods to the object.

 

An interface only forces an object to have a particular set of methods and it doesn't tell you how the method should be implemented. It's a semantic thing.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...