Вот еще одна типичная ситуация. Многие программные инструменты должны сохранять "историю", что позволяет пользователям:
Такой механизм привлекателен для любой интерактивной среды, однако его создание требует больших усилий. Поэтому историю поддерживают лишь немногие инструменты (к примеру, ряд "командных оболочек" Unix и Windows), да и те нередко частично. Универсальные же решения не зависят от конкретного инструмента. Их можно инкапсулировать в класс, а от него - породить другой класс для управления рабочей сессией любого инструмента. (Решение с применением классов-клиентов допустимо, но не так привлекательно.) И снова без множественного наследования не обойтись, так как недостаточно иметь родителя, знающего только историю.
Набор полезных возможностей предоставляет класс TEST, инкапсулирующий ряд механизмов тестирования класса: прием и хранение данных от пользователя, вывод и хранение результата, сравнение, регрессное тестирование и т.д. Хотя решение с использованием вложения может быть предпочтительным, неплохо иметь возможность при тестировании класса X определять класс X_TEST, порожденный от X и TEST.
Далее мы будем встречать и другие примеры наследования функциональных возможностей, при котором один класс F инкапсулирует набор, например констант или методов математической библиотеки, а другой, объявляя себя потомком F, может ими воспользоваться.