The idea behind an abstract class is that you can define some common functionality of a set of similar classes, but leave other details up to the implementing (extending) classes. In a way they are similar to interfaces, except that you can actually implement some of the functions in the abstract class.

But what's the point, I hear you ask? Well, you only have to write the common code once, although you can do this in a concrete (non-abstract) base class too. But also you may not want other programmers to instantiate the base class, so this is where the real power of abstract classes come in.

Let me show an example to help illustrate my point. Imagine you are writing a program to classify all of the animals in a zoo. Animals can be classified into certain types, bird, reptile, mammal, insect, arachnid, fish, etc, and then down to their species such as dog, cat, parrot or kangaroo. The base class, Animal, can provide some of the common functionality to all of these. It might have a function called eat() which all animals do in a similar way and so the function is written out to describe the process of an animal eating. It might contain another function, walk(), but this one is abstract, since different animals will implement this in a different way. All subclasses of the Animal class will need to implement this method.

The major bonus of this is that somewhere in your code you can call a function that takes an Animal as a parameter. You know that you can call the eat() and walk() functions on this parameter because all Animals can eat and walk. This is called polymorphism and is an important trait of Object Oriented Programming.

I hope this has helped you. Please feel free to discuss or ask further questions if you still can't see the value of abstract classes.

So let me just check if I understand this correctly.

Animal is an abstract class with the methods eat() and walk() with walk() being abstract. And if you had the class Reptile() you would write it as follows:

Yes, except that you don't have to define the code for Reptile::eat() because it is in the Animal class. If you wanted to change the way that the Reptile eats from the way that the Animal eats then you would need to redefine it. And of course you can use a call to parent::eat() like you can with any extending class if you want to extend the eat() method rather than simply overriding it.

All of this adds up to the fact that you can minimise the amount of code and simplify the code maintenance by using an abstract base class in a package of similar classes.

Ok, I think I'm beginning to understand this better. Thanks a lot for the explanation darkagn. I really appreciate it

Abstract classes can also be used to hide complex code, while still being extensible.

Say implementing the Animal class was quite involved and complex, now someone who didn't know about Animals wanted to use the features of Animals but didn't want to go into the gory details could use it to model a Reptile with limited knowledge. (A better example would be, if you wanted to download email, but didn't want to go into the details of the POP3 or IMAP protocol, you could use an abstract POP3 class)

A good model of relationships:
If Reptile extends Animal, then you know an Animal is more general then a Reptile. These make it easier to make sense of the relationships in a bunch of code.

A way of defining interfaces, guides or structure
If there is an Animal abstract class, then all types of animals must extend the animal class to also be animals. This gives a single interface within a PHP application. A real example would be a abstract Storage class providing an interface for Databases, Sessions, File storage etc. Down the chain, the Database class could be abstract also for the different Database types (mysql, sqlite, flat file, etc.). This provides a level of control, structure and order within the app and is also used as a base to implement other programming patterns successfully.

Modular, less conflicting, good for Teamwork etc.
When working with a team, abstract classes really make it easier to understand what the others are doing, and contribute also. Each person could be working on separate functionality that share the same common base (abstract class) without conflict.

Not to forget making it easier to modify stuff later on. The difference between having to fix up a bunch of procedural code, and those with well defined relationships is huge.