Abstract classes, interfaces and good class design

Pure virtual functions

Sometimes a base class cannot sensibly do the job itself. What is the area of a "Shape" in general? There is no answer. Writing = 0 after a virtual function declares it pure virtual: the base gives no implementation, and every concrete derived class must provide one.

class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;     // pure virtual
};

// Shape s;            // error: cannot create an object of abstract class Shape
class Square : public Shape {
public:
    explicit Square(double side) : side_(side) {}
    double area() const override { return side_ * side_; }
private:
    double side_;
};
Square sq(3);          // fine: Square implements area()

Interfaces

Java and C# have an interface keyword. C++ does not; instead, an interface is an abstract class that has only pure virtual functions and a virtual destructor, and no data. Code that uses the interface depends only on "what can be done", not "how it is done". This makes it easy to swap implementations, for example a real SMS gateway in production and a fake one in tests.

class PaymentGateway {                  // an interface
public:
    virtual ~PaymentGateway() = default;
    virtual bool charge(const std::string& account, long long paise) = 0;
};

class Checkout {
public:
    explicit Checkout(PaymentGateway& gw) : gw_(gw) {}   // depends on the interface
    bool placeOrder(const std::string& acc, long long paise) {
        return paise > 0 && gw_.charge(acc, paise);
    }
private:
    PaymentGateway& gw_;
};

class FakeGateway : public PaymentGateway {             // used in tests
public:
    bool charge(const std::string&, long long) override { ++calls; return true; }
    int calls = 0;
};

Composition over inheritance, again

Deep inheritance trees (Vehicle → Car → ElectricCar → LuxuryElectricCar) become rigid: a change at the top ripples down everywhere. Many modern designs keep inheritance shallow: an interface at the top and concrete classes directly below it, with extra features added by holding other objects as members (composition).

Multiple inheritance, briefly

C++ allows a class to inherit from several bases: class Phone : public Camera, public MusicPlayer. Inheriting from several INTERFACES is common and safe. Inheriting data from several bases that share a common base leads to the "diamond problem" (two copies of the shared base), which C++ solves with virtual inheritance. As a learner, avoid diamonds; prefer interfaces plus composition.

Design checklist

1. Does the derived class truly satisfy "is-a" everywhere the base is used? If not, use composition.
2. Is the base class meant to be used polymorphically? Then give it a virtual destructor.
3. Mark every override with override.
4. Keep data private; give derived classes protected functions rather than protected data when you can.
5. Hold polymorphic objects in std::unique_ptr<Base> (single owner) inside containers.