(я боюсь, что вообще не туда попал. Здесь все очень серьёзные)

По рекомендации господина LaptevVV, я осмелюсь предложить Вашему вниманию краткую выжимку из своего опыта и ряд соображений. Здесь речь идёт об управлении многообразием графических компонентов, известное как комбинаторный взрыв.
Если это окажется интересным, то я постараюсь экстраполировать свой опыт по этой теме, написать библиотеку и оформить статью.

За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.

Классическим руководством по этой тематике я считаю книгу Гради Буча про ООП. В ней есть ряд хороших примеров по построению иерархии классов и объектов с методами рисования и управления.

Следующим этапом исследования этой темы является библиотека Objective View на C++ от компании Stingray. Несмотря на то, что такой компании уже нет, реализованная архитектура MVC – модель, вид, контроллер, до сих пор является актуальной.

С точки зрения GUI эта тема имеет множество реализаций, начиная от WIN_API_32 – MFC, виджетами *nix – X-Windows и заканчивая множеством других подобных технологий.

Существенным вкладом в тему я считаю технологию Ангуляр 2. Основы её разрабатывались тогда (2008 – 2010 гг), когда я увлечённо писал собственную библиотеку. Теперь я нахожу много эффективных сходств. Прежде всего – это контекст. Во-вторых, — это каскадные свойства.

Это было введением в тему.
А теперь – постановка задачи:
— При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п.
Таким образом проявляется эффект комбинаторного взрыва.
Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.

Что же можно сделать? И причём тут тензорная архитектура?
Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства:
1. пространство пользовательских операций,
2. пространство команд для стека Undo/Redo,
3. пространство управляемых компонентов,
4. пространство способностей компонентов — элементов.

Теперь рассмотрим эти пространства подробнее.

1.Пространство пользовательских операций.
Каждая операция должна иметь метод или признак срабатывания. При этом, надо учитывать что обращение к каждой операции происходит в последовательном цикле. К сожалению, ничего более умного пока придумать не удалось. Может быть введение кодов типа MouseMove что-то изменит.
Кстати!
Вы можете существенно облегчить свой редактор, если будете игнорировать MouseMove, который происходит слишком часто.
Для интерактивной программы достаточно опрашивать позицию курсора синхронно с частотой обновления экрана – 40 Гц.
Здесь ещё надо добавить, что ряд операций захватывают управление. Типа перетаскивания.
Значит Вам надо где-то хранить: координаты курсора, нажатые клавиши, активную операцию и т.п.
Вот здесь мы приходим к пониманию важного класса – Контекст Управления. Его экземпляр нам надо передавать в каждую операцию, как при опознавании актуальной операции, так и при её реализации.

2.Пространство команд для стека Undo/Redo.
Надеюсь, что всем понятно – пользовательские операции не меняют объектов редактирования, за исключением операций выделения, изменением масштаба вида, положения холста и т.п.
Потому что при редакции они должны порождать команды.
В архитектуре MVC эта тема очень хорошо проработана.
Надо заметить, что в тензорной архитектуре нам придётся писать большинство команд не для компонентов, а для их элементов.

3.Пространство управляемых компонентов.
В идеале, класс компонента должен быть одним, универсальным. Объект этого класса — это та единица, с которой работает пользователь.
Что он должен делать? – Иметь список своих элементов-способностей и работать с Контекстом Управления. А именно: быть активным, выделенным, перемещаться, копироваться, трансформироваться, быть группой или членом группы и т.п.
Однако есть исключения. Такие компоненты, как Холст, Лист и Вид, легче породить от универсального класса как частный случай.

4.Пространство способностей компонентов – элементов.
Здесь сосредоточена вся работа: способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, трансформации, эффекты, связки, стрелочки и т.п. Поскольку элементы заносятся в список компонента, то пользователь может настраивать свои компоненты динамически, определяя порядки и способности.

Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов!
Всё будет очень жёстко и фирма изнасилует много программистов, чтобы добиться элементарного единообразия.

При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.

***
Я очень надеюсь, что для программистов с опытом создания редакторов — тема ясна.
Я очень надеюсь, что для всяких специалистов — тема будет интересна и полезна.
Прошу не вдаваться в демагогию. И требовать от меня определений — пока не надо. Тема ещё сырая.

Далее — мне проще приводить конкретный код с комментариями, чтобы постепенно довести его до практической применимости.
Пускай мой код служит доказательством. Чтобы мы не уходили в словоблудие.

(я боюсь, что вообще не туда попал. Здесь все очень серьёзные)

По рекомендации господина LaptevVV, я осмелюсь предложить Вашему вниманию краткую выжимку из своего опыта и ряд соображений. Здесь речь идёт об управлении многообразием графических компонентов, известное как комбинаторный взрыв. Тема актуальна для разработчиков всевозможных редакторов, САПР и игр.
Если это окажется интересным, то я постараюсь экстраполировать свой опыт по этой теме, написать библиотеку и оформить статью.

За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.

Классическим руководством по этой тематике я считаю книгу Гради Буча про ООП. В ней есть ряд хороших примеров по построению иерархии классов и объектов с методами рисования и управления.

Следующим этапом исследования этой темы является библиотека Objective View на C++ от компании Stingray. Несмотря на то, что такой компании уже нет, реализованная архитектура MVC – модель, вид, контроллер, до сих пор является актуальной.

С точки зрения GUI эта тема имеет множество реализаций, начиная от WIN_API_32 – MFC, виджетами *nix – X-Windows и заканчивая множеством других подобных технологий.

Существенным вкладом в тему я считаю технологию Ангуляр 2. Основы её разрабатывались тогда (2008 – 2010 гг), когда я увлечённо писал собственную библиотеку. Теперь я нахожу много эффективных сходств. Прежде всего – это контекст управления. Во-вторых, — это каскадные свойства.

Это было введением в тему.
А теперь – постановка задачи:
— При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п.
Таким образом проявляется эффект комбинаторного взрыва.
Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.

Что же можно сделать? И причём тут тензорная архитектура?
Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства:
1. пространство пользовательских операций,
2. пространство команд для стека Undo/Redo,
3. пространство управляемых компонентов,
4. пространство способностей компонентов — элементов.

Теперь рассмотрим эти пространства подробнее.

1.Пространство пользовательских операций.
Каждая операция должна иметь метод или признак срабатывания. При этом, надо учитывать что обращение к каждой операции происходит в последовательном цикле. К сожалению, ничего более умного пока придумать не удалось. Может быть введение кодов типа MouseMove что-то изменит.
Кстати!
Вы можете существенно облегчить свой редактор, если будете игнорировать MouseMove, который происходит слишком часто.
Для интерактивной программы достаточно опрашивать позицию курсора синхронно с частотой обновления экрана – 40 Гц.
Здесь ещё надо добавить, что ряд операций захватывают управление. Типа перетаскивания.
Значит Вам надо где-то хранить: координаты курсора, нажатые клавиши, активную операцию и т.п.
Вот здесь мы приходим к пониманию важного класса – Контекст Управления. Его экземпляр нам надо передавать в каждую операцию, как при опознавании актуальной операции, так и при её реализации.

2.Пространство команд для стека Undo/Redo.
Надеюсь, что всем понятно – пользовательские операции не меняют объектов редактирования, за исключением операций выделения, изменением масштаба вида, положения холста и т.п.
Потому что при редакции они должны порождать команды.
В архитектуре MVC эта тема очень хорошо проработана.
Надо заметить, что в тензорной архитектуре нам придётся писать большинство команд не для компонентов, а для их элементов.

3.Пространство управляемых компонентов.
В идеале, класс компонента должен быть одним, универсальным. Объект этого класса — это та единица, с которой работает пользователь.
Что он должен делать? – Иметь список своих элементов-способностей и работать с Контекстом Управления. А именно: быть активным, выделенным, перемещаться, копироваться, трансформироваться, быть группой или членом группы и т.п.
Однако есть исключения. Такие компоненты, как Холст, Лист и Вид, легче породить от универсального класса как частный случай.

4.Пространство способностей компонентов – элементов.
Здесь сосредоточена вся работа: способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, трансформации, эффекты, связки, стрелочки и т.п. Поскольку элементы заносятся в список компонента, то пользователь может настраивать свои компоненты динамически, определяя порядки и способности.

Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов!
Всё будет очень жёстко и фирма изнасилует много программистов, чтобы добиться элементарного единообразия.

При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.

***
Я очень надеюсь, что для программистов с опытом создания редакторов — тема ясна.
Я очень надеюсь, что для всяких специалистов — тема будет интересна и полезна.
Прошу не вдаваться в демагогию. И требовать от меня определений — пока не надо. Тема ещё сырая.

Далее — мне проще приводить конкретный код с комментариями, чтобы постепенно довести его до практической применимости.
Пускай мой код служит доказательством. Чтобы мы не уходили в словоблудие.