В целом распсиховавшийся тигр прав: кроме наследования есть и другие способы задать общую функциональность разным классам, и один из них - написать класс, статическими методами реализующий всю желаемую функциональность для наследников дисплейобжекта, чтобы все методы первым аргументом принимали ссылку на этот самый объект, над которым нужно производить действия.

А какой способ логичнее? Создавать контейнер и помещать туда объекты или писать класс для управления объектами?

Создавать контейнер и помещать туда объекты
писать класс для управления объектами - не совсем в стиле ооп

Разве писать класс, для управления объектами - это не в стиле ооп? Черт возьми...

>>Разве писать класс, для управления объектами - это не в стиле ооп? Черт возьми...

В классическом ООП принято разделять класс-итератор(управляющий контейнером) и класс-контейнер.
Смотреть, например, boost(http://www.boost.org/), классическую c++-библиотеку, обязательное знание которой, кстати, насколько я знаю, требуют при приеме на работу сишника в яндекс.

на сколько я понимаю это стуктурный подход.
описываем структуру, описываем отдельно функции по работе с этой структурой.

Помоему, обобщения в таких вопросах не логичны. Всё должно определяться структурой приложения. Иногда выгодно, чтобы методы управления классом находились в самом классе и из главного приложения вызывались по необходимости, а иногда чтобы был управляющий класс и управлял событиями(не Event'ами) по заданному алгоритму.

согласен, но в данном случае (описаном автором), как раз лучше использовать контейнер