CAD, IDE, всякие текстовые редакторы. Можно долго не думать и сделать клиент-сервер, слабую связность везде, но два вопроса:
1. Накладные расходы -> теряется скорость отклика.
2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.
Что можно почитать на тему проектирования таких штук?
Re: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>CAD, IDE, всякие текстовые редакторы. Можно долго не думать и сделать клиент-сервер, слабую связность везде, но два вопроса:
C>1. Накладные расходы -> теряется скорость отклика. C>2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.
Ну чудес не бывает, если В должен знать про А, то он должен знать.
Иногда можно сделать подписку на события, чтобы развязать компоненты. Но система подписок частенько превращается в жуткий говнокод, который невозможно отлаживать/поддерживать.
Явно заданная связь между компонентами — не самое плохое решение.
В общем, надо смотреть по месту.
C>Что можно почитать на тему проектирования таких штук?
Чисто про десктопные приложения ничего не попадалось.
Так что "Чистая архитектура" и "Паттерны проектирования" — по-прежнему нашефсё!
Один раз, правда, попала в лапы книга одного из разработчиков Mentor Expedition, но там общие рекомендации про уменьшение зависимостей и прочее, что можно было прочесть и у Саттера/Мейерса/банды 4-х.
Занятно, что, несмотря на "правильность" книги, внутри Экспедишена был лютый АдЪ из выделений по new и интрузивных списков. В дебаге запускать было бесполезно
_____________________
С уважением,
Stanislav V. Zudin
Re: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>1. Накладные расходы -> теряется скорость отклика.
Ну а в другом месте — приобретается. C>2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.
Странно, что эти вопросы у тебя в 50 лет только появились. Может лучше не начинать? C>Что можно почитать на тему проектирования таких штук?
Классику, начиная с Бертрана Мейерса и архитектуры компьютера, потом по восходящей до интерпрайз паттернов Фаулера. Эта тема которую нельзя понять по одной книжке, только комплексное изучение предмета даёт понимание как строить системы.
CAD, это фактически 3Д движок и мало чем от него отличается, а по движкам всё написано уже, а можно и код посмотреть.
Sic luceat lux!
Re: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>CAD, IDE, всякие текстовые редакторы. Можно долго не думать и сделать клиент-сервер, слабую связность везде, но два вопроса: C>1. Накладные расходы -> теряется скорость отклика. C>2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда. C>Что можно почитать на тему проектирования таких штук?
C>Что можно почитать на тему проектирования таких штук?
Хехе... работаю над вполне себе полноценным редактором 3D, при этом там еще и IDE для программирования, и дебаггер, и вагон всяких необычных UI, и вообще много всего. Включая клиент-сервер в прямом смысле этого слова.
На тему проектирования могу предложить прочитать какое-нибудь руководство ассенизатора. Судя по некоторым знакомым из Adobe, ситуация аналогичная.
Единственное, что действительно важно — это система и способ подключения плагинов. Так, чтобы они не могли слишком легко сломать приложение-хост.
Re[2]: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, SkyDance, Вы писали:
SD>Хехе... работаю над вполне себе полноценным редактором 3D, при этом там еще и IDE для программирования, и дебаггер, и вагон всяких необычных UI, и вообще много всего. Включая клиент-сервер в прямом смысле этого слова.
Какой ЯП (или набор оных)? У меня пока в планах С++ для ядра, C# для логики, UI написать два раза: под Linux (GTK) и Windows (WinUI 3).
SD>На тему проектирования могу предложить прочитать какое-нибудь руководство ассенизатора
Не гуглится ничего кроме говновоза
SD>Единственное, что действительно важно — это система и способ подключения плагинов. Так, чтобы они не могли слишком легко сломать приложение-хост.
В точку. Я пытался эту проблему описать через пример с зависимостями, но понял, что я сам не знаю, почему приложения падают от планигов. А падают они у всех. Что Blender, Inkscape, FreeCAD, что продукты JetBrains.
Re[3]: Что почитать про архитектуру тяжёлых настолок?
C>Какой ЯП (или набор оных)? У меня пока в планах С++ для ядра, C# для логики, UI написать два раза: под Linux (GTK) и Windows (WinUI 3).
C, C++ и очень много Lua. UI на Qt, от которого уже 5-7 лет как идут попытки избавиться, и замена реально идет case by case. Очень уж тяжело выкорчевывать.
C>Не гуглится ничего кроме говновоза
Правильно! Потому что никакой "архитектуры" ни у кого нет, есть просто нагромождение исторических слоев и интеграций.
C>В точку. Я пытался эту проблему описать через пример с зависимостями, но понял, что я сам не знаю, почему приложения падают от планигов. А падают они у всех. Что Blender, Inkscape, FreeCAD, что продукты JetBrains.
Потому что даже очень хорошо sandboxed плагины работают без оглядки друг на друга, устраивая совершенно неожиданные race conditions. Так что сам по себе каждый плагин отлично работает в изоляции, но когда, например, два линтера друг другу рвут глотку, получается всякая фигня.
Re[3]: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, SkyDance, Вы писали:
SD>>Хехе... работаю над вполне себе полноценным редактором 3D, при этом там еще и IDE для программирования, и дебаггер, и вагон всяких необычных UI, и вообще много всего. Включая клиент-сервер в прямом смысле этого слова. C>Какой ЯП (или набор оных)? У меня пока в планах С++ для ядра, C# для логики, UI написать два раза: под Linux (GTK) и Windows (WinUI 3).
Почему бы не сделать один UI на Qt? Или на Electron? VS Code на Electron работает нормально, так что можно пробовать.
Здравствуйте, SkyDance, Вы писали:
C>>Какой ЯП (или набор оных)? У меня пока в планах С++ для ядра, C# для логики, UI написать два раза: под Linux (GTK) и Windows (WinUI 3).
SD>C, C++ и очень много Lua. UI на Qt, от которого уже 5-7 лет как идут попытки избавиться, и замена реально идет case by case. Очень уж тяжело выкорчевывать.
На внутренние библиотеки. Причин несколько; в первую очередь, потому, что на Lua не получается писать Qt-интерфейс. Во-вторую, Qt тащит за собой всякие разные зависимости, реализация которых (вот тот же std::string) недостаточно производительна и/или не имеет некоторых фич. Это, конечно, специфика продукта: для многих других, не связанных с геймдевом продуктов, подобные экивоки попросту не требуются.
Re: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>CAD, IDE, всякие текстовые редакторы. Можно долго не думать и сделать клиент-сервер, слабую связность везде, но два вопроса:
C>2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.
C>Что можно почитать на тему проектирования таких штук?
Если тебе нужно узнать в компоненте B о том, что что-то произошло в компоненте A, то есть два варианта.
Вариант 1. Схема: Publisher <-> через Event <-> Listener. Так работают делегаты в C#. На них, например, построена обработка событий в WinForms, WPF и Avalonia. Аббревиатур типа MVC там навалом (никогда к ним серьезно не относился; ну, назвали и назвали загадочными буковками, а дальше что?)
Вариант 2. Есть другая разновидность (ближе к стилю функционального программирования): Observable <-> через Subscribe <-> удалять прослушивание через IDisposable. Это уже то ли реактивное функциональное, то ли функциональное реактивное, но программирование. Вечно путаю. А их авторы почему-то обижаются, когда путают эти названия.
Кстати, мне на F# нравится использовать оба подхода.
Я не уверен, что ты именно это спрашивал. А так, тема для десктопостроения одна из краеугольных — как обрабатывать события, как создать механизм обратного вызова.
Теперь ты написал, что собираешься делать ядро на C++. Сам язык скудноват для этого (но это не помешало сделать свои механизмы в GTK и WxWidgets — из этой пары использовал только GTK3, да и то из коммон-лиспа ). Поэтому в Qt пошли на кардинальную меру. Сильно так расширили язык C++ и ввели механизм сигналов-слотов, который в свою очередь сильно завязан на свою собственную модель работы с памятью (дочерние объекты, родительские). Такая вещь в себе получилась. Если напишешь на Qt, то уйти от него потом будет сложно (выше по топику уже жаловались). Поэтому С++ вместе с Qt, считай, что почти отдельный язык — надмножество над C++ (Apple тоже когда-то экспериментировало с подобным подходом в Objective-C и Objective-C++, но потом ушли от этого).
Для твоей связки C++ (ядро) и C# (логика) могло бы идеально подойти C++/CLI, но, к сожалению, эта штука не работает за пределами винды, хотя идея мне очень понравилась. Здесь Микрософт можно понять и простить.
А так, боюсь, что реализовать взаимодействие между C++ и C# будет тем еще геморроем. Обратный вызов из нативного кода — штука сложная, особенно, из-за сборки мусора
Re[2]: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, dsorokin, Вы писали:
D>Для твоей связки C++ (ядро) и C# (логика) могло бы идеально подойти C++/CLI, но, к сожалению, эта штука не работает за пределами винды, хотя идея мне очень понравилась. Здесь Микрософт можно понять и простить.
D>А так, боюсь, что реализовать взаимодействие между C++ и C# будет тем еще геморроем. Обратный вызов из нативного кода — штука сложная, особенно, из-за сборки мусора
Разве последний .NET не стал полностью кросс-платформенным?
Re[3]: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>... C>Разве последний .NET не стал полностью кросс-платформенным?
.NET может и стал, а вот фреймворки для GUI — в лучшем случае условно-кроссплатформенные. Например, WPF работает на платформах где есть DirectX, то есть никакими линуксами, макосями и мобилками там даже и не пахнет.
А вот Qt прекрасно с этим справляется. Хотя на практике очень много людей кричат что Qt плох, но при этом их знания застряли на виджетах и подходах времён wtl. QtQuick — очень крутая технология для современного десктопа. Причём как один из вариантов клиент-серверных приложений, который значительно ускоряет ci/cd — это сервер плюс wasm клиент.
Re: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, cppguard, Вы писали:
C>1. Накладные расходы -> теряется скорость отклика. C>2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.
C>Что можно почитать на тему проектирования таких штук?
Для тяжелых вещей я бы предложил для начала отказаться от всякой модной реактивщины типа rx, и смотреть в стороную олдскульных вариантов MVC.
Что бы в одном источнике — такое вряд ли. Не так уж и много тяжелого десктопа вообще было в общей массе. бОльшая часть приложений не сложнее todomvc.
Кстати говоря, https://todomvc.com/ — можете тут посмотреть, но нужно копать именно олдскульный MVC, а не фронтовые поделки
Фронтенд большей частью куцые приложения, и смасштабировать на ваш кейс не выйдет.
Вам нужен хороший MVC
1. внятный контроллер
2. годная модель
Тяжелый десктоп в своё время пилили виде, похожем на hexagonal architecture — в центре приложения это модель и бизнеслогика, безо всяких зависимостей на файлы, соединения, базы данных итд.
Импорт, экспорт, загрузка, сохранение, алгоритмы над моделью — это всё клиенты. БД точно так же, приклеивается как клиент к модели. UI это точно такой же клиент, только у него есть промежуточная view model для локальных приседаний.
Основная модель в данном случае просто хранит данные приложения и данные конкретного рабочего проекта, т.е. appliction и document. Почти вся бизнеслогика навешивается как слой над моделью. БЛ тоже не имеет никаких зависимостей наружу.
UI может быть почти любым. Я бы предложил простую схему —
ui всё что может, делает на локальном состоянии, — та самая view model.
остальное нужно отсылать в контролер, вызовом controller.dispatch(action, parameters)
контроллер резолвит хандлер, и передает управление
хандлер в контроллере просто вызывает нужную функцию из БЛ,
или дергает сервис (загрузка, сохранение, импорт, экспорт итд), т.е. — утилита, которая модифицирует модель, или создаёт новую.
главное, что все изменения модели должно инициироваться контроллером, и никем больше.
в конце контролер тригерит обновление ui
каждый ui view обновляет свою view model
плагины подкидываются обычно в контроллер — их задача — обработка конкретных экшнов, по стандартной схеме. Еще вариант — плагин может быть сервисом.
Теоретически, всё можно сделать плагином, но лучше определится с этим заранее.
В такой схеме у вас к сущностям А и Б будут соответсвующие объекты в модели, они могут иметь ссылки друг на друга. Главное что бы у вас был четкое правило — всё состояние хранится в модели.
Re[6]: Что почитать про архитектуру тяжёлых настолок?
Здравствуйте, SkyDance, Вы писали:
SD>На внутренние библиотеки. Причин несколько; в первую очередь, потому, что на Lua не получается писать Qt-интерфейс. Во-вторую, Qt тащит за собой всякие разные зависимости, реализация которых (вот тот же std::string) недостаточно производительна и/или не имеет некоторых фич. Это, конечно, специфика продукта: для многих других, не связанных с геймдевом продуктов, подобные экивоки попросту не требуются.
А можно поинтересоваться, std::string недостаточно производительный, или не имеет некоторых фич?
Если недостаточно производительный, то как вы улучшили производительность? А если фичи, то чего не хватает?
M>А можно поинтересоваться, std::string недостаточно производительный, или не имеет некоторых фич?
Это я промахнулся, не string, а std::string_view (в основном для замены const std::string&). Родная реализация делает что-то странное. Я уже не помню, что именно, но что-то там с in-place mutation и возвратом this.
Re[7]: Что почитать про архитектуру тяжёлых настолок?
