{"title":"Abstract Classes","description":null,"content":"An abstract class is a class that is intentionally incomplete. It declares operations that derived classes must fill in, while still being usable as a common type for those derived classes. This lesson focuses on why abstract classes exist, when to use one, and how they shape the design of an E-Commerce system.\n\n---\n\n# What Makes a Class Abstract\n\nA class becomes abstract the moment it contains at least one pure virtual function. The previous section covered the `= 0` syntax, so the focus here is on the consequence, not the spelling. The consequence is direct: you cannot instantiate the class directly, but you can still use it as a base, as a pointer type, and as a reference type.\n\nA small `PaymentProcessor` example grounds the idea.\n\n\n```cpp\n#include \n#include \n\nclass PaymentProcessor {\npublic:\n virtual void charge(double amount) = 0;\n virtual std::string name() const = 0;\n virtual ~PaymentProcessor() = default;\n};\n\nclass CreditCardProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"Charging $\" << amount << \" to credit card.\" << std::endl;\n }\n std::string name() const override { return \"CreditCard\"; }\n};\n\nint main() {\n CreditCardProcessor card;\n card.charge(49.99);\n std::cout << \"Processor: \" << card.name() << std::endl;\n return 0;\n}\n```\n\n\n`PaymentProcessor` is abstract. `CreditCardProcessor` is concrete because it provides bodies for both pure virtuals. If you tried `PaymentProcessor p;`, the compiler would refuse and tell you the class is abstract.\n\n---\n\n# Why Abstract Classes Exist\n\nAbstract classes solve two problems at once.\n\nThe first is **contract enforcement**. When you declare a function pure virtual in the base, every concrete derived class is forced to implement it. The compiler will not let a derived class forget. That guarantee removes a whole category of runtime surprises where a method exists but does nothing useful.\n\nThe second is **modeling incomplete concepts**. \"Payment processor\" is not a thing you can build on its own. You can build a credit card processor, a PayPal processor, a bank transfer processor. The abstract class captures what they all share without pretending the shared idea is something you can construct.\n\nPut differently, a concrete class answers \"what is this thing?\" and an abstract class answers \"what role does this thing play?\".\n\nThe same idea as a hierarchy:\n\n\n```mermaid\nflowchart TD\n PP[PaymentProcessor
abstract]:::primary\n CC[CreditCardProcessor]:::secondary\n PAY[PayPalProcessor]:::secondary\n BT[BankTransferProcessor]:::secondary\n\n PP --> CC\n PP --> PAY\n PP --> BT\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe arrows go from base to derived. The base sits at the top as an abstract contract. The leaves are the only classes you would create instances of.\n\n---\n\n# You Can't Instantiate, But You Can Reference\n\nAbstract classes are forbidden as values, but they are valid as pointers and references. That is the point.\n\n\n```cpp\n#include \n#include \n\nclass PaymentProcessor {\npublic:\n virtual void charge(double amount) = 0;\n virtual ~PaymentProcessor() = default;\n};\n\nclass PayPalProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"Charging $\" << amount << \" via PayPal.\" << std::endl;\n }\n};\n\nint main() {\n PayPalProcessor concrete;\n\n PaymentProcessor& ref = concrete;\n PaymentProcessor* ptr = &concrete;\n\n ref.charge(15.00);\n ptr->charge(22.50);\n\n return 0;\n}\n```\n\n\nThe variable `concrete` is the actual object. `ref` and `ptr` are handles that look at it through the abstract type. The virtual dispatch handles the rest, so `ref.charge` ends up running `PayPalProcessor::charge` because that is the actual type of the object behind the reference.\n\nThis is what makes the abstract class useful as a parameter type, a return type, and the element type of a polymorphic container.\n\n---\n\n# Abstract Classes as Function Parameters\n\nOnce you can take a reference or pointer to an abstract type, you can write functions that accept any concrete derivation without naming them.\n\n\n```cpp\n#include \n#include \n\nclass PaymentProcessor {\npublic:\n virtual void charge(double amount) = 0;\n virtual std::string name() const = 0;\n virtual ~PaymentProcessor() = default;\n};\n\nclass CreditCardProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[Card] Charged $\" << amount << std::endl;\n }\n std::string name() const override { return \"CreditCard\"; }\n};\n\nclass BankTransferProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[Bank] Transferred $\" << amount << std::endl;\n }\n std::string name() const override { return \"BankTransfer\"; }\n};\n\nvoid checkout(PaymentProcessor& processor, double cartTotal) {\n std::cout << \"Using \" << processor.name() << \" to pay $\" << cartTotal << std::endl;\n processor.charge(cartTotal);\n}\n\nint main() {\n CreditCardProcessor card;\n BankTransferProcessor bank;\n\n checkout(card, 89.99);\n checkout(bank, 120.00);\n\n return 0;\n}\n```\n\n\n`checkout` does not know anything about credit cards or bank transfers. It only knows it has something that can be charged and that knows its own name. That is the contract `PaymentProcessor` enforces, and the function works with any class that signs that contract.\n\nThe parameter is `PaymentProcessor&`, not `PaymentProcessor`. If you tried to pass by value, the compiler would reject it because you cannot have a value of an abstract type. By-value would also slice the object, throwing away the derived part, a problem covered back in the polymorphism section.\n\nPassing by reference (or pointer) to the abstract base has negligible cost. Each virtual call adds one extra pointer dereference through the vtable, which is small compared to anything that does real work like a network call or a database write.\n\n---\n\n# Abstract Classes Can Have Data and Real Functions\n\nAn abstract class is not limited to a list of pure virtuals. It can have data members, regular member functions, and constructors. The abstractness comes from the unimplemented operations, not from a lack of everything else.\n\n\n```cpp\n#include \n#include \n\nclass DiscountStrategy {\nprotected:\n std::string code;\n\npublic:\n DiscountStrategy(const std::string& promoCode) : code(promoCode) {}\n\n virtual double applyTo(double cartTotal) const = 0;\n\n std::string promoCode() const { return code; }\n\n void describe() const {\n std::cout << \"Promo: \" << code << std::endl;\n }\n\n virtual ~DiscountStrategy() = default;\n};\n\nclass PercentageDiscount : public DiscountStrategy {\n double percent;\npublic:\n PercentageDiscount(const std::string& promoCode, double pct)\n : DiscountStrategy(promoCode), percent(pct) {}\n\n double applyTo(double cartTotal) const override {\n return cartTotal * (1.0 - percent / 100.0);\n }\n};\n\nclass FlatDiscount : public DiscountStrategy {\n double amount;\npublic:\n FlatDiscount(const std::string& promoCode, double amt)\n : DiscountStrategy(promoCode), amount(amt) {}\n\n double applyTo(double cartTotal) const override {\n double result = cartTotal - amount;\n return result < 0.0 ? 0.0 : result;\n }\n};\n\nint main() {\n PercentageDiscount summer(\"SUMMER20\", 20.0);\n FlatDiscount welcome(\"WELCOME10\", 10.0);\n\n summer.describe();\n std::cout << \"Cart after SUMMER20: $\" << summer.applyTo(80.0) << std::endl;\n\n welcome.describe();\n std::cout << \"Cart after WELCOME10: $\" << welcome.applyTo(45.0) << std::endl;\n\n return 0;\n}\n```\n\n\n`DiscountStrategy` holds the promo code as a data member, has a constructor that initializes it, and exposes a regular `promoCode()` getter plus a `describe()` function with a real body. Every derived class inherits all of that. Only `applyTo` is left for them to implement.\n\nDerived constructors call the base constructor through the member initializer list, exactly like with any other inheritance. The base's constructor runs first, sets up its data members, and then the derived constructor runs. The abstractness changes nothing about the construction order.\n\n---\n\n# A Third Hierarchy: Shipping Methods\n\nOne more example reinforces the pattern. Different shipping methods compute different costs and quote different delivery times, but the order code should not care which one is in use.\n\n\n```cpp\n#include \n#include \n\nclass ShippingMethod {\npublic:\n virtual double cost(double cartTotal) const = 0;\n virtual int estimatedDays() const = 0;\n virtual std::string label() const = 0;\n virtual ~ShippingMethod() = default;\n};\n\nclass StandardShipping : public ShippingMethod {\npublic:\n double cost(double cartTotal) const override {\n return cartTotal > 50.0 ? 0.0 : 4.99;\n }\n int estimatedDays() const override { return 5; }\n std::string label() const override { return \"Standard\"; }\n};\n\nclass ExpressShipping : public ShippingMethod {\npublic:\n double cost(double) const override { return 12.99; }\n int estimatedDays() const override { return 1; }\n std::string label() const override { return \"Express\"; }\n};\n\nvoid quoteShipping(const ShippingMethod& method, double cartTotal) {\n std::cout << method.label()\n << \": $\" << method.cost(cartTotal)\n << \", arrives in \" << method.estimatedDays() << \" day(s)\"\n << std::endl;\n}\n\nint main() {\n StandardShipping std_ship;\n ExpressShipping express;\n\n quoteShipping(std_ship, 60.00);\n quoteShipping(express, 60.00);\n\n return 0;\n}\n```\n\n\n`quoteShipping` is written once and works for both methods. If a new `OvernightShipping` shows up next year, it derives from `ShippingMethod`, implements the three pure virtuals, and `quoteShipping` works with it without changing a line.\n\n\n```mermaid\nflowchart LR\n Order[Order Code]:::caller\n Method[ShippingMethod
abstract]:::primary\n Std[StandardShipping]:::secondary\n Exp[ExpressShipping]:::secondary\n Over[OvernightShipping
added later]:::green\n\n Order -->|uses| Method\n Method --- Std\n Method --- Exp\n Method --- Over\n\n classDef caller fill:#38d9a9,stroke:#000,color:#000\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe order code on the left depends only on the abstract type in the middle. New concrete shipping methods plug in on the right without touching the order code at all.\n\n---\n\n# Returning Abstract Types from Functions\n\nYou cannot return an abstract type by value (same reason you cannot pass by value). You can return a pointer or a smart pointer to one. This is the shape of a factory function, covered in detail later. The relevant piece for this lesson is that abstract classes are first-class return types when wrapped in indirection.\n\n\n```cpp\n#include \n#include \n#include \n\nclass PaymentProcessor {\npublic:\n virtual void charge(double amount) = 0;\n virtual std::string name() const = 0;\n virtual ~PaymentProcessor() = default;\n};\n\nclass CreditCardProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[Card] $\" << amount << std::endl;\n }\n std::string name() const override { return \"CreditCard\"; }\n};\n\nclass PayPalProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[PayPal] $\" << amount << std::endl;\n }\n std::string name() const override { return \"PayPal\"; }\n};\n\nstd::unique_ptr makeProcessor(const std::string& choice) {\n if (choice == \"card\") {\n return std::make_unique();\n }\n return std::make_unique();\n}\n\nint main() {\n auto p1 = makeProcessor(\"card\");\n auto p2 = makeProcessor(\"paypal\");\n\n p1->charge(19.99);\n p2->charge(35.50);\n\n return 0;\n}\n```\n\n\n`makeProcessor` returns a `std::unique_ptr`. The caller gets a smart pointer to the abstract base, never knowing or caring which concrete type came back. That hidden choice is what abstraction buys you. The caller writes `p1->charge(19.99)` and the runtime picks the correct `charge` based on the actual type the pointer holds.\n\n`std::make_unique` performs one heap allocation per object. For a payment processor created once per checkout this is negligible. For millions per second, pooling or reuse would be preferable.\n\nA few notes on this pattern. Returning `std::unique_ptr` works because the smart pointer holds a pointer internally, and pointers to abstract types are valid. Returning `PaymentProcessor` directly would not compile. Returning `PaymentProcessor*` (a raw pointer) would compile but force the caller to remember to delete it, which is the kind of bug the smart pointer prevents.\n\nA later lesson covers factory functions in detail. For now the takeaway is that abstract types are usable as return types when wrapped in some form of indirection.\n\n---\n\n# Holding Many in a Polymorphic Container\n\nA single function parameter can take any concrete derivation. So can a single container element. A `std::vector>` is a list of \"anything that is a payment processor,\" and the code that walks it does not need to know what is inside.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass PaymentProcessor {\npublic:\n virtual void charge(double amount) = 0;\n virtual std::string name() const = 0;\n virtual ~PaymentProcessor() = default;\n};\n\nclass CreditCardProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[Card] charged $\" << amount << std::endl;\n }\n std::string name() const override { return \"CreditCard\"; }\n};\n\nclass PayPalProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[PayPal] charged $\" << amount << std::endl;\n }\n std::string name() const override { return \"PayPal\"; }\n};\n\nclass BankTransferProcessor : public PaymentProcessor {\npublic:\n void charge(double amount) override {\n std::cout << \"[Bank] transferred $\" << amount << std::endl;\n }\n std::string name() const override { return \"BankTransfer\"; }\n};\n\nint main() {\n std::vector> processors;\n processors.push_back(std::make_unique());\n processors.push_back(std::make_unique());\n processors.push_back(std::make_unique());\n\n double cartTotal = 75.00;\n\n for (const auto& p : processors) {\n std::cout << \"Trying \" << p->name() << \"... \";\n p->charge(cartTotal);\n }\n\n return 0;\n}\n```\n\n\nThe vector stores `unique_ptr` elements. Each pointer points to a different concrete type, but the loop treats them identically. Virtual dispatch picks the correct `charge` and the correct `name` for each one.\n\nThe runtime picture:\n\n\n```mermaid\nflowchart LR\n V[vector elements]:::caller\n P0[ptr 0]:::primary\n P1[ptr 1]:::primary\n P2[ptr 2]:::primary\n CC[CreditCardProcessor]:::secondary\n PP[PayPalProcessor]:::secondary\n BT[BankTransferProcessor]:::secondary\n\n V --> P0\n V --> P1\n V --> P2\n\n P0 --> CC\n P1 --> PP\n P2 --> BT\n\n classDef caller fill:#38d9a9,stroke:#000,color:#000\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nEach element is a smart pointer of the same static type. Each one points to a different concrete object on the heap. That is polymorphism, end to end.\n\n---\n\n# Common Mistakes\n\nA few patterns come up when working with abstract classes.\n\nThe first is **trying to pass or store by value**. Anything that needs to hold an abstract type has to hold it through a pointer or reference. `PaymentProcessor p`, `std::vector`, and `PaymentProcessor make()` all fail to compile.\n\nThe second is **forgetting the virtual destructor**. If you delete a derived object through a pointer to the abstract base, and the base does not declare its destructor `virtual`, only the base destructor runs. Resources held by the derived part leak. The rule: abstract base classes that are ever deleted polymorphically need `virtual ~Base() = default;`.\n\nThe third is **assuming abstract means \"no data\"**. As the `DiscountStrategy` example showed, an abstract class can carry data, regular methods, and constructors. It is only abstract because at least one operation is left unimplemented, not because it lacks state.\n\nThe fourth is **not marking the override**. The `override` keyword is not required, but using it catches mistakes where a derived function does not actually match the base signature. Without `override`, a typo in the signature creates a brand-new function on the derived class and the pure virtual stays unimplemented, which leaves the derived class abstract by accident.\n\n---\n\n# When to Use an Abstract Class\n\nAbstract classes are not the answer to every problem. Use one when all of the following are true.\n\nYou have a clear \"is-a\" relationship between a general concept and several specific variations. Payment processors, shipping methods, and discount strategies all fit this. A \"thing that has a vector inside it\" does not.\n\nThe code that uses the concept does not need to know which specific variation it is dealing with. The checkout function does not care which payment processor; the order code does not care which shipping method. If your caller is constantly checking \"is this a CreditCard or a PayPal?\", the abstraction is not pulling its weight.\n\nYou expect new variations over time, or you want existing variations to be swappable. The cost of an abstract base pays off when the alternative is editing the caller every time a new option appears.\n\nIf none of those apply, a plain class or a free function is probably the better fit. Abstraction has a cost. Every layer adds one more thing for a reader to chase, and every virtual call adds one indirection. Use it where it pays for itself.","pageType":"cpp"}

Abstract Classes

Get Premium