Підсумки

Висновки

Інтерфейс описує потрібну клієнтові можливість. Композиція поєднує контекст зі змінним алгоритмом. Спільна віртуальна база усуває дублювання стану ромба. Час життя невласних зв’язків є частиною контракту.

Питання для самоперевірки

1. Що робить клас абстрактним?
2. Чому чисто віртуальний деструктор потребує визначення?
3. Хто ініціалізує віртуальну базу?
4. Чим virtual-наслідування відрізняється від virtual-методу?
5. Як NVI гарантує спільну перевірку?
6. Чи можна замістити private-віртуальний метод?
7. Що вирішують кваліфіковане ім’я та using?
8. Коли кілька інтерфейсів кращі за один великий?
9. Хто володіє стратегією у прикладі Order?
10. Який ризик має підписка через сирий вказівник?
11. Що стається з redo після нової команди?
12. Як підготувати історію до можливого винятку алокації?
13. Що таке міксин і які ризики імен він додає?
14. Чому layout-схема не дозволяє reinterpret_cast між ролями?
15. Коли обрати статичний, а коли динамічний поліморфізм?

Корисні посилання

• https://learn.microsoft.com/cpp/cpp/abstract-classes-cpp
• https://learn.microsoft.com/cpp/cpp/multiple-base-classes
• https://isocpp.org/wiki/faq/multiple-inheritance