Класс Window должен покрывать функциональность окон, которая имеется
в различных оконных системах. Рассмотрим два крайних подхода:
- пересечение функциональности. Интерфейс класса Window предоставляет
только операции, общие для всех оконных систем. Однако в результате мы
получаем интерфейс не богаче, чем в самой слабой из рассматриваемых
систем. Мы не можем воспользоваться более развитыми средствами, даже если
их поддерживает большинство оконных систем (но не все);
- объединение функциональности. Создается интерфейс, который включает
возможности всех существующих систем. Здесь нас подстерегает опасность
получить чрезмерно громоздкий и внутренне не согласованный интерфейс.
Кроме того, нам придется изменять его (а вместе с ним и Lexi) всякий раз,
как только производитель переработает интерфейс своей оконной системы.
Ни то, ни другое решение «в чистом виде» не годятся, поэтому мы выберем
компромиссное. Класс Window будет предоставлять удобный интерфейс,
поддерживающий наиболее популярные возможности оконных систем. Поскольку
редактор Lexi будет работать с классом Window напрямую, этот класс должен
поддерживать и сущности, о которых Lexi известно, то есть глифы. Это означает, что
интерфейс класса Window должен включать базовый набор графических
операций, позволяющий глифам отображать себя в окне. В табл. 2.3 перечислены
некоторые операции из интерфейса класса Window.

Еще бы описал виртуальное наследование для полноты ... было бы ваще супер.

Наследование - не обязательно расширяет функционал, а расширение функционала - не обязательно наследование. Это ортогональные понятия.

Никто.