When do we need an abstract class?

[Emerald214]

I don't understand why i must have an abstract class.
Why must we begin with class 'Shape' instead of class 'TwoDimensionShape'?

[Lindley]

Well, C++ doesn't have a concept of an "abstract class" as such. The closest it has is pure virtual classes.

When would a class *need* to be pure virtual? Never. But it might make sense to make it pure virtual if there's no sense in constructing an object of that type directly. For instance, if "Shape" has an area() method, it doesn't make sense to construct a Shape since there's no formula for the area of a generic shape; only derived classes (maybe Square, Circle, etc) will have such formulas, so it would make sense to give them area() methods and make Shape be pure virtual.

As for why you'd need to use inheritance at all? Well, let's say we have Squares and Circles, which are both derived from Shapes, and we want to store an array of everything we've got. We could do

vector<Square*> allSquares;
vector<Circle*> allCircles;

and store the two types of things separately. But that might lead to code duplication if we're going to do the same thing to both arrays anyway. Instead, since a Square IS-A Shape and a Circle IS-A shape, we could store *all* of our shapes in one place with

vector<Shape*> allShapes;

This is the sort of concept that starts to make more sense as you use it.

[Speedo]

Generally, when you want to have a common interface for something, but you don't want to specify one particular type as the default.

Say you're dealing with animals...

class Animal
{
public:
  virtual ~Animal( ) { }
  
  virtual void walk( ) = 0;
  virtual void sleep( ) = 0;
  virtual bool isHungry( ) = 0;
  virtual void eat(Plant& meal) = 0;
  virtual void eat(Animal& meal) = 0;  
  // etc
};

class Horse : public Animal
{
  // ...
};

class Lion : public Animal
{
  // ...
};

class Sparrow : public Animal
{
  // ...
};

It doesn't make sense to allow the construction of a generic Animal. What type of animal should it be? What good is it to have an animal that you don't know anything about? Etc... so we just say in effect "all animals should include the following, but you have to specifically define what they do before you can create them" by using an ABC.

And of course, the same can apply at intermediate levels as well. If you have a lot of animals that are of a similar type, you might want to change the animal example to something like

// class Animal as above

class Cat : public Animal
{
public:
  virtual ~Cat( ) { }
  
  virtual void hunt( ) = 0;
  virtual void groom( ) = 0;
};

class Bird : public Animal
{
public:
  virtual ~Bird( ) { }
  
  virtual void fly( ) = 0;
};

class Lion : public Cat
{
  // ...
};

class Sparrow : public Bird
{
  // ...
};

[laserlight]

I suggest that you read these articles (in PDF format)

• The Open-Closed Principle
• The Liskov Substitution Principle
• The Dependency Inversion Principle

The third article is really the one that answers your question (see the "Separating Interface from Implementation in C++" section), but you need to know the first two concepts to be able to understand the third.

EDIT:

Well, C++ doesn't have a concept of an "abstract class" as such. The closest it has is pure virtual classes.

To be fair, Stroustrup defines "abstract class" in his C++ glossary, but does not list "pure virtual class" in that same glossary.

[Emerald214]

Thanks all of you.
@laserlight: thank you but it's so complicated with me... I just unserstand OCP T.T

[JohnW@Wessex]

I suppose one example of The Liskov Substitution Principle could be the iostreams in the STL.

eg.

int value;

mystream << value;

This is valid regardless of whether the stream is an ofstream, ostringstream or a reference to cout. As long as it's derived from ostream, the calling code doesn't really care.

An example of The Dependency Inversion Principle could be an object that accepts an ostream as a directive as to where the output should be written to. The object is not interested in what the specific stream is, only that it presents the expected interface.

[_uj]

I don't understand why i must have an abstract class.
Why must we begin with class 'Shape' instead of class 'TwoDimensionShape'?

First of all you don't need abstract classes. But if you do use them your code becomes more general. General code is the objective of abstract classes.

If you use TwoDimensionShape variables in your code, the code will work with objects of that class only. But if you use Shape variables in your code it will work with objects of any class derived from Shape. It will work with TwoDimensionShape objects but that's just for starters. Your code will work with objects of any class you care to derive from Shape.