Роблячи спадщину приватною, ви в основному говорите, що навіть той факт, що B успадковує від A (взагалі), є приватним - недоступним / видимим для зовнішнього світу.
Не вдаючись до довготривалого обговорення того, що сталося б, якби це було дозволено, простий факт полягає в тому, що це заборонено. Якщо ви хочете використовувати вказівник на базу для посилання на об'єкт похідного типу, то ви в значній мірі застрягли у використанні загальнодоступного успадкування.
Приватна спадщина не обов'язково (або навіть зазвичай) має відповідати принципу заміщення Ліскова . Загальнодоступне успадкування стверджує, що похідний об'єкт можна замінити об'єктом базового класу, і належна семантика все одно призведе. Приватне успадкування цього не стверджує. Звичайний опис відносин, що мають на увазі приватне успадкування, "реалізується з точки зору".
Публічне успадкування означає, що похідний клас підтримує всі можливості базового класу і, можливо, додає ще більше. Приватне успадкування часто означає більш-менш протилежне: що похідний клас використовує загальний базовий клас для реалізації чогось із більш обмеженим інтерфейсом.
Тільки для прикладу, припустимо на даний момент, що контейнери в стандартній бібліотеці C ++ були реалізовані з використанням успадкування, а не шаблонів. У поточній системі std::deque
і std::vector
є контейнерами, і std::stack
є адаптером контейнера, що забезпечує більш обмежений інтерфейс. Оскільки він базується на шаблонах, ви можете використовувати його std::stack
як адаптер для std::deque
або std::vector
.
Якби ми хотіли надати по суті те саме зі спадщиною, ми б, мабуть, використовували приватну спадщину, тому std::stack
було б щось на зразок:
class stack : private vector {
};
У цьому випадку ми однозначно не хочемо, щоб користувач мав змогу маніпулювати нашими, stack
як ніби vector
. Це могло (і, можливо, могло б) порушити очікування стека (наприклад, користувач міг вставляти / видаляти елементи посередині, а не чисто як стек, як передбачалося). В основному ми використовуємо vector
як зручний спосіб реалізації нашого стека, але якщо (наприклад) ми змінили реалізацію на stack
самостійну (без залежності від базового класу) або повторно реалізуємо її з точки зору std::deque
, ми не хочемо цього щоб вплинути на будь-який клієнтський код - для клієнтського коду це повинен бути лише стек, а не якийсь спеціалізований різновид векторів (або deque).
protected