Use aggregation like LSP in C++

Question

I was reading about LSP (Liskov Substitution Principle) in a book called Clean Architecture: A Craftsman's Guide to Software Structure and Design. I have a question regarding how this would be implemented in C++.

On page 95, there is a figure explaining LSP using a simple example:

My interpretation of the figure in C++:

// License.h
class License {
    public:
    virtual calcFee();
};


// PersonalLicense.h

#include "License.h"
class PersonalLicense : public License {
};


// BusinessLicense.h

#include "License.h"
class BusinessLicense : public License{
    private:
    someDataType users;
};

To my understanding, Billing will be using PersonalLicense and BusinessLicense (and other derivatives) potentially, so Billing.h will contain #include-s for all their header files:

// Billing.h
#include "PersonalLicense.h"
#include "BusinessLicense.h"
...

My concern is that
a) if there are a lot of License derivatives, Billing.h will have to include all of them, and
b) it looks like Billing.h will have to be edited to include every new kind of License.
Is this the case? Or am I missing something?

Update

After reading the answer by Ryathal, I am now under the impression that I misunderstood the above figure. I was understanding the diagram as Billing has a License, which doesn't seem to be correct.

The aforementioned answer says that "This would be used in something like a shopping cart that does have references to all the different license types". This makes me think that the original diagram is incorrect, and that it should look like this instead (ShoppingCart has a License).

Assumptios based on the above

1. class License is defined in file named License.h.
2. class PersonalLicense is defined in file named PersonalLicense.h and includes License.h.
3. class BusinessLicense is defined in file named BusinessLicense.h and includes License.h.
4. class ShoppingCart is defined in file named ShoppingCart.h and its member function has expressions as such:

...
list<License*> orders;
orders.add(new PersonalLicense());
orders.add(new BusinessLicense());
...

Questions

1. Which of the diagrams is correct, if any?
2. Is the diagram possible to implement using C++?
3. If we have multiple License types, let's say 5 ~ 10, do we have to include each header into ShoppingCart.h? Or is there any way of including as little headers as possible? I'm unsure how all this works in practice.

Answer 1

First things first: the UML diagram

The original diagram is syntactically correct (except for the <I> on the box boundary, which should be «interface» centered above Licence in plain UML).

The diagram means, that Billing objects are associated to specific Licence objects and have access to their public feature, e.g. they may invoke their calculateFee() operation for calculating the bill. The open-headed arrow means moreover that it is guaranteed that Billing objects can efficiently find the associated License objects.

The revised diagram is also correct. Hint: the use of the white aggregation diamond is not wrong, but it does not add any meaning to the diagram (despite a popular belief): the UML specifications still leave its semantics undefined.

The main difference between the two diagrams is the multiplicity (it's unspecified in the first diagram, which in reality means that it's one to one if you take the UML specs by the book; it's one-to-many in the second).

C++ implementation - step 1, polymorphism

The diagram can be perfectly implemented in C++, using polymorphism. However, polymorphism requires some additional effort in C++.

The following example is not polymorphic and doomed to fail for your use case, because the way C++ handles objects:

class ShoppingCart {
public: 
    ...
private:
    std::vector<License> items;   // or std::list, if you prefer
};

The following alternative would be polymorphic:

class ShoppingCart {
public: 
    ...
private:
    std::vector<License*> items;   // the pointer allows to point to subtypes
};

But still, this is not sufficient. For polymorphism to work, the polymorphic object must also make the function that might be specialized virtual:

class License {
public: 
    virtual double calculateFee(); // ok double is not great for money, but it's another story
    virtual ~License();   // if one function is virtual, better foresee a virtual destructor as well
};

With this in place, the shopping cart would not need to know anything about the many different kind of licenses that exist. The compiler will make sure that in the following call the right member function is called:

total += items[n]->calculateFee(); 

C++ implementation, step 2: Headers

You should have self contained headers that include no more other headers than strictly needed to compile. So in your case ShoppingCart.h should only include License.h. If it doesn't compile, go to StackOverflow if necessary.

The only reason you would need the other headers, is if shopping cart would be responsible of the creation of the licenses:

orders.add(new PersonalLicense());
orders.add(new BusinessLicense()); 

But this should not be a responsibility of the shopping cart. Because this would indeed require the cart to know much to much on all the specializations. What you should have is some code like:

class ShoppingCart {
public: 
    void addItem(License* l); 
    double calculateTotal();  
private:
    std::vector<License*> items;   // the pointer allows to point to subtypes
};

So some other module would do the glue between the different kind of licenses and the shopping cart. If you'd really have to let the cart create the items, then you'd need to use a factory to keep it general.

And LSP in all this?

LSP means that your license specialization all continue to fulfill the contract guaranteed by License, so that whenever you use a License, you could exchange it with a more specialized license and the could would still work (as the contract is guaranteed).

If you don't have a polymorphic design in the first place, it makes no sense to talk about LSP.

Answer 2

For a demo of the Liskov Substitution Principle the header for Billing would only have License. The point of the LSP is that any object that extends another doesn't break that base functionality. Since Billing only knows about License for the LSP to be followed every extension must have an implementation of CalcFee that relies only on properties/functions that exist within license. When you violate the LSP its a good signal that your chosen abstraction is poor and you need to rethink the design. Inheritance really only works in somewhat small numbers (5 different licenses ok, 10+ might be a problem), in part because of the difficulty of following the LSP, which is why composition is more encouraged today as you can include similar functionality to objects, without directly relating them.

This is what Billing would look like:

Billing
{
  GetTotalFees(List<License> lic)
  {
    int total=0;
    foreach ( l in lic)
      total+=l.calcFee();
  }
}

This would be used in something like a shopping cart that does have references to all the different license types, so you could do something like:

Order.add(PersonalLicense);
Order.add(BusinessLicense);
Order.add(FishingLicense);
price=Billing.GetTotalFees(Order);

Answer 3

If the user of the class tree - Billing in your example - needs to #include the header files for all your derived classes, then you're doing it wrong.

The first thing to try is not #include-ing them. If your code still compiles, then you didn't need them.

If it does break, then that suggests you're using features of the derived classes that aren't in the base one. This isn't actually a violation of the LSP, but is a "code smell". Ask yourself why the other classes don't implement that feature, even if it's a "do nothing" option. For example, if some licencees get discounts and others don't, then give all classes a "CalculateDiscount" function. Ones that don't get discounts can return zero. Such functions could be implemented in C++ as virtual functions on the base class, that derived classes may override if they wish.