(я боюсь, что вообще не туда попал. Здесь все очень серьёзные)
По рекомендации господина 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, который происходит слишком часто.
Для интерактивной программы достаточно опрашивать позицию курсора синхронно с частотой обновления экрана – 25 Гц.
Здесь ещё надо добавить, что ряд операций захватывают управление. Типа перетаскивания.
Значит Вам надо где-то хранить: координаты курсора, нажатые клавиши, активную операцию и т.п.
Вот здесь мы приходим к пониманию важного класса – Контекст Управления. Его экземпляр нам надо передавать в каждую операцию, как при опознавании актуальной операции, так и при её реализации.
2.Пространство команд для стека Undo/Redo.
Надеюсь, что всем понятно – пользовательские операции не меняют объектов редактирования, за исключением операций выделения, изменением масштаба вида, положения холста и т.п.
Потому что при редакции они должны порождать команды.
В архитектуре MVC эта тема очень хорошо проработана.
Надо заметить, что в тензорной архитектуре нам придётся писать большинство команд не для компонентов, а для их элементов.
3.Пространство управляемых компонентов.
В идеале, класс компонента должен быть одним, универсальным. Объект этого класса — это та единица, с которой работает пользователь.
Что он должен делать? – Иметь список своих элементов-способностей и работать с Контекстом Управления. А именно: быть активным, выделенным, перемещаться, копироваться, трансформироваться, быть группой или членом группы и т.п.
Однако есть исключения. Такие компоненты, как Холст, Лист и Вид, легче породить от универсального класса как частный случай.
4.Пространство способностей компонентов – элементов.
Здесь сосредоточена вся работа: способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, трансформации, эффекты, связки, стрелочки и т.п. Поскольку элементы заносятся в список компонента, то пользователь может настраивать свои компоненты динамически, определяя порядки и способности.
Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов!
Всё будет очень жёстко и фирма изнасилует много программистов, чтобы добиться элементарного единообразия.
При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.
***
Я очень надеюсь, что для программистов с опытом создания редакторов — тема ясна.
Я очень надеюсь, что для всяких специалистов — тема будет интересна и полезна.
Прошу не вдаваться в демагогию. И требовать от меня определений — пока не надо. Тема ещё сырая.
Далее — мне проще приводить конкретный код с комментариями, чтобы постепенно довести его до практической применимости.
Пускай мой код служит доказательством. Чтобы мы не уходили в словоблудие.
Здравствуйте, LVE, Вы писали:
LVE>По рекомендации господина LaptevVV, я осмелюсь предложить Вашему вниманию краткую выжимку из своего опыта и ряд соображений. Здесь речь идёт об управлении многообразием графических компонентов, известное как комбинаторный взрыв. Тема актуальна для разработчиков всевозможных редакторов, САПР и игр. LVE>Если это окажется интересным, то я постараюсь экстраполировать свой опыт по этой теме, написать библиотеку и оформить статью.
LVE>За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.
Судя по написанному ниже, игрушек было больше (вот такое сложилось мнение). А т.к. подходы для проектирования принципиально разные, то я не стал бы собирать всё в одну кучу.
LVE>Следующим этапом исследования этой темы является библиотека Objective View на C++ от компании Stingray. Несмотря на то, что такой компании уже нет, реализованная архитектура MVC – модель, вид, контроллер, до сих пор является актуальной.
Стингреевские контролы в свое время были неплохи. Ихнее MVC для графических редакторов ну никак не вписывалось. Может для каких-нибудь табличных редакторов оно и пригодно —
LVE>А теперь – постановка задачи: LVE>- При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п. LVE>Таким образом проявляется эффект комбинаторного взрыва. LVE>Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
Но тут пришел наш камрад Андрей Федонюк (АКА c-smile) и одним махом решил все проблемы, создав замечательную библиотеку htmlayout.
LVE>Что же можно сделать? И причём тут тензорная архитектура? LVE>Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства:
LVE>1.Пространство пользовательских операций. LVE>Каждая операция должна иметь метод или признак срабатывания. При этом, надо учитывать что обращение к каждой операции происходит в последовательном цикле. К сожалению, ничего более умного пока придумать не удалось. Может быть введение кодов типа MouseMove что-то изменит.
Непонятное утверждение. Какая операция? В каком цикле?
Жмякнули на checkbox, получили уведомление, обработали событие. Где цикл?
LVE>Кстати! LVE>Вы можете существенно облегчить свой редактор, если будете игнорировать MouseMove, который происходит слишком часто. LVE>Для интерактивной программы достаточно опрашивать позицию курсора синхронно с частотой обновления экрана – 25 Гц.
Мой опыт подсказывает, что MouseMove приходит реже, чем 25Гц.
Поэтому если надо делать графический редактор, то лучше привязываться к MouseMove. Для игр, где графика должна быть плавной и изображение может меняться без участия пользователя (анимация — дует ветер, деревья колышутся, персонаж стоит и ковыряется в носу) нужна привязка к FPS.
LVE>Здесь ещё надо добавить, что ряд операций захватывают управление. Типа перетаскивания. LVE>Значит Вам надо где-то хранить: координаты курсора, нажатые клавиши, активную операцию и т.п. LVE>Вот здесь мы приходим к пониманию важного класса – Контекст Управления. Его экземпляр нам надо передавать в каждую операцию, как при опознавании актуальной операции, так и при её реализации.
Для этого существуют конечные автоматы. А контекст элементарный — исходное положение курсора + текущее положение курсора.
LVE>2.Пространство команд для стека Undo/Redo. LVE>Надеюсь, что всем понятно – пользовательские операции не меняют объектов редактирования, за исключением операций выделения, изменением масштаба вида, положения холста и т.п. LVE>Потому что при редакции они должны порождать команды.
Агащяззз.
Существует два способа реализации Undo/Redo.
1. "действие-антидействие" (АКА паттерн "Команда")
2. Сделать snapshot БД перед началом редактирования (паттерн "состояние").
Первый способ применим для дискретных операций — удалить объект, сменить состояние крыжика.
А вот если тебе надо переместить объект, а во время перемещения надо объект отрисовывать, попутно перестраивая какие-нибудь связи... тут я пожелаю тебе удачи. Здесь необходим второй метод.
Реализация второго способа простая, достаточно хранить не всю базу, а только модифицируемые объекты.
Оба способа легко комбинируются.
LVE>3.Пространство управляемых компонентов. LVE>В идеале, класс компонента должен быть одним, универсальным. Объект этого класса — это та единица, с которой работает пользователь. LVE>Что он должен делать? – Иметь список своих элементов-способностей и работать с Контекстом Управления. А именно: быть активным, выделенным, перемещаться, копироваться, трансформироваться, быть группой или членом группы и т.п. LVE>Однако есть исключения. Такие компоненты, как Холст, Лист и Вид, легче породить от универсального класса как частный случай.
Как только появляются связи между объектами (или компонентами в твоей терминологии??? я уже запутался), так все эти общие классы летят к чертям.
Можно выделить некоторые общие интерфейсы, но это предел.
С интерфейсами, кстати, есть занятная проблема. Полиморфизьм это, конечно, замечательно. Но! Следует помнить, что алгоритмы определяют структуры данных, а не наоборот. Можно нарисовать красивые структуры данных, разные там интерфейсы, но если из-за этого алгоритм из O(N) превращается в О(N^3), то нафиг такие структуры данных.
LVE>4.Пространство способностей компонентов – элементов. LVE>Здесь сосредоточена вся работа: способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, трансформации, эффекты, связки, стрелочки и т.п. Поскольку элементы заносятся в список компонента, то пользователь может настраивать свои компоненты динамически, определяя порядки и способности.
Если говорить о редакторе, то число состояний каждого компонента конечно. Определяется на уровне представления (View в MVC).
LVE>Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов! LVE>Всё будет очень жёстко и фирма изнасилует много программистов, чтобы добиться элементарного единообразия.
LVE>При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.
Это в обычной архитектуре будет примерно l + m + n методов (k — лишнее, а кстати, что такое k? ), без всяких комбинаторных взрывов.
LVE>Я очень надеюсь, что для программистов с опытом создания редакторов — тема ясна.
LVE>Далее — мне проще приводить конкретный код с комментариями, чтобы постепенно довести его до практической применимости. LVE>Пускай мой код служит доказательством. Чтобы мы не уходили в словоблудие.
Сдается мне, Владимир Евгенич, что ты сильно усложняешь.
Но подождём кода.
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Тензорная архитектура на примере интерактива
Я рад Вашему вниманию к теме.
Сожалею, что не могу ответить на все Ваши замечания.
Давайте знакомиться. Меня зовут – Владимир Евгеньевич.
Меня интересует создание учебных пособий по интерактивной графике и по тензорной архитектуре.
Всё хочется сделать с пошаговой демонстрацией рабочего кода.
Я ориентируюсь на С#. Можно продублировать код на С++.
Вы можете выступить в качестве соавтора методички, если представите свою концепцию интерактивных взаимодействий.
Я уверен, что Ваш опыт будет очень интересен читателям.
Более того. Вы можете выступить в качестве эксперта по интерактивным технологиям, но только если есть возможность документально подтвердить свою квалификацию.
Здравствуйте, LVE, Вы писали:
LVE>Что же можно сделать? И причём тут тензорная архитектура? LVE>Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства: LVE>1. пространство пользовательских операций, LVE>2. пространство команд для стека Undo/Redo, LVE>3. пространство управляемых компонентов, LVE>4. пространство способностей компонентов — элементов.
Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Меня интересует создание учебных пособий по интерактивной графике и по тензорной архитектуре.
Благое начинание, а есть потребность в таком учебном пособии?
Методичка обычно пишется в формате "делай так". Такой формат хорош для выполнения отдельно взятой задачи, но в общем виде, для расширения кругозора, кмк не подходит.
Если есть чем поделиться, то лучше книга в формате "как я рожал ёжиков", т.е. с описанием задачи, проблем, с которыми пришлось столкнуться и способов, какими эти проблемы разрулили.
В качестве примера замечательная книжица (думаю, в библиотеке возможно найти).
LVE>Вы можете выступить в качестве соавтора методички, если представите свою концепцию интерактивных взаимодействий. LVE>Я уверен, что Ваш опыт будет очень интересен читателям.
У нас, я подозреваю, несколько различный взгляд на проблему, передерёмся Поэтому сразу беру самоотвод.
LVE>Более того. Вы можете выступить в качестве эксперта по интерактивным технологиям, но только если есть возможность документально подтвердить свою квалификацию.
Даже не представляю, как можно документально подтвердить квалификацию.
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Тензорная архитектура на примере интерактива
Здравствуйте, alpha21264, Вы писали:
A>Чё пристал? A>Ну нравится человеку слово "тензор". A>Он таким образом воспринимает многомерность и независимость этих ваших "концернов".
A>Я под его влиянием даже начал книжку про тензоры читать
Не, ну тогда, конечно, польза есть
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов.
Ну да, если копирайт налепить на любое сочетание слов, оно, конечно же станет осмысленным
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, Arsen.Shnurkov, Вы писали:
A>>Ну нравится человеку слово "тензор". A>>Я под его влиянием даже начал книжку про тензоры читать
AS>А силён ли ты в "миварных технологиях"?
Оооо, какая интересная штучка!
Слово такое вижу впервые, но про что-то подобное много думал.
Может быть и силён. Начну с того, что про это почитаю.
Течёт вода Кубань-реки куда велят большевики.
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
LVE>>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов. V>Ну да, если копирайт налепить на любое сочетание слов, оно, конечно же станет осмысленным
Мне совершенно не важно — что вы думаете об этом сочетании слов.
Мне интересно то, что вы можете сделать, услышав их.
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
AS>>А силён ли ты в "миварных технологиях"? LVE>Похоже наш ТРИЗ украли, перевели, а теперь нам обратно его впаривают.
Не, похоже это что-то для распила бюджета
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Мне совершенно не важно — что вы думаете об этом сочетании слов. LVE>Мне интересно то, что вы можете сделать, услышав их.
Сделать я могу только одно: заявить о том, что не понимаю их смысла.
По начальному посту — это просто частный случай SoC. По крайней мере, я не понял, в чём отличие.
Если сможете объяснить — тогда смогу прокомментировать подробнее.
А так — разбить систему на подзадачи и компоненты, чтобы не было связей всех со всеми — это абсолютно типовая задача любого проектировщика ПО.
Под которую давно уже есть и теоретическая база и метрики качества этой работы (coupling/cohesion) и эмпирические правила по её осуществлению.
Само разбиение будет, естественно, разным для разных решаемых задач.
Re[6]: Тензорная архитектура на примере интерактива
V> Под которую давно уже есть и теоретическая база и метрики качества этой работы
И такой код с Undo/Redo уже написано на C# (я его не сам писал, но в моём репозитории на Github такой есть)
приведённое топикстартером решение является банальностью, которая применяется в графических редакторах лет 15 точно.
И всё это вещается с жутчайшим апломбом, мол "20 лет опыта, внимайте мне, меня волнует как я вас вдохновил".
Re[7]: Тензорная архитектура на примере интерактива
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>И такой код с Undo/Redo уже написано на C# (я его не сам писал, но в моём репозитории на Github такой есть) AS>приведённое топикстартером решение является банальностью, которая применяется в графических редакторах лет 15 точно. AS>И всё это вещается с жутчайшим апломбом, мол "20 лет опыта, внимайте мне, меня волнует как я вас вдохновил".
Твоё возмущение — абсолютно не обосновано. Банальная зависть и личная неприязнь.
А вот у меня есть серьёзные основания для развития этой темы.
Дело в том, что множество фирм имеют либо избыток ресурсов, либо тырят готовые компоненты без оглядки.
Ярким примером этого является то, что частенько в редакторе ввода и в окне вывода — используются разные шрифты.
Меня это напрягает, потому что иногда я публикую таблицы.
В такой ситуации я не знаю — как будет выглядеть моё сообщение и как сделать так, чтобы всё было выровнено.
Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
