архитектура приложения а-ля графический редактор Опции

[call_me_Frank]

Алоха всем!

Вот такая задачка на этот раз:

Редактор работает с документами, документ может находиться или в режиме редактирования, или в режиме просмотра.
Документ заключает в себя набор элементов. Предок всех элементов - класс GLYPH, конкретная реализация - EGLYPH (поддерживает редактирование) и MGLYPH (поддерживает только отображение). Интерфейсы всех трех классов одинаковые, документ работает только с классом GLYPH. GLYPH наследуется от QWidget.

EGLYPH отличается от своего родителя тем, что переопределяет события мышки, клавиатуры и др. - там и определяются его возможности редактирования.

Теперь мне надо сделать так, чтобы у меня был набор классов элементов (кривая, рисунок, прямоугольник...), каждый из которых мог бы быть создан либо как элемент для отображения, либо как элемент для редактирования, в зависимости от режима документа.

Я думаю над применением паттерна "декоратор", но пока что столкнулся с необходимостью делать public-обертки для функций обработки событий в классе GLYPH, т.к. они являются protected, и их не получается переопределить в классе-декораторе, да и вообще в голове крутятся разные способы реализации...

Хочу найти оптимальный и гибкий вариант, что посоветуете?

[call_me_Frank]

Сам создал тему, сам буду и отвечать

С "декоратором" ничего не вышло, пришлось сделать "декоратор"- наоборот:

при создании GLYPH, я передаю ему некоторый обработчик

GLYPH * new_elt = new GLYPH(new EDITOR_GLEVT());

обработчик при этом знает, на кого работает - то есть получает указатель на объект GLYPH, в конструктор которого он был послан.

внутри класса GLYPH я делегирую обработку нужных событий обработчику (GLEVT * evt):

void GLYPH::keyPressEvent(QKeyEvent *ev){
    //

    evt->key_pressed(ev);
}

в целом, получил то, что хотел - разные обработчики дают возможность варьировать поведение элемента без того, чтобы плодить иерархию классов от самого элемента.