Забавно, если стиль моего ответа на комментарий показался результатом llm, но нет - все писалось ручками. Согласен, с псевдокодом было бы легче соотнести описание с реальным кодом. Но существует еще и визуальное проектирование (те же диаграммы UML), грубо говоря, описанные в статье сущности можно представить в контексте объектно-ориентированного стиля отдельными классами с агрегацией экземпляров других классов.
Согласен, что некоторые теги, которые обычно ассоциируют с представлением реализации на определенном ЯП, могут немного запутать читателя. С другой стороны, проектирование программного продукта часто занимает высший приоритет, т.к. в современных системах стараются не делать жесткую связь между описанием системы и её конкретной реализацией.
Но важно учесть, что в некоторых областях, исходный функционал продукта может быть косвенно связан с технологиями, на которых планируется данный функционал реализовать. Пример: разбиение исходной задачи на независимые этапы, которые можно легко переложить на конвейерные системы при использовании FPGA.
Один и тот же процесс можно отразить используя разные представления. Описанное в статье представление не является самым совершенным или универсальным. Оно выделяет определенные свойства для анализа.
Можно сказать, что каждое представление отсекает часть информации исходно объекта анализа. При другом анализе потребуется выделить другие свойства объекта с использованием других представлений.
У conan 2 есть как много минусов, так и много плюсов. С одной стороны, он очень гибкий, поэтому не несет в себе ровно один сценарий использования при организации своих проектов/ библиотек, с другой стороны - он показывает к чему нужно стремиться при проектировании многомодульных систем и дает все инструменты для этого.
Да и его поддерживают производители множества библиотек, т.к. выгладывают своевременно новые версии библиотек в conancenter.
Забавно, если стиль моего ответа на комментарий показался результатом llm, но нет - все писалось ручками.
Согласен, с псевдокодом было бы легче соотнести описание с реальным кодом. Но существует еще и визуальное проектирование (те же диаграммы UML), грубо говоря, описанные в статье сущности можно представить в контексте объектно-ориентированного стиля отдельными классами с агрегацией экземпляров других классов.
Согласен, что некоторые теги, которые обычно ассоциируют с представлением реализации на определенном ЯП, могут немного запутать читателя. С другой стороны, проектирование программного продукта часто занимает высший приоритет, т.к. в современных системах стараются не делать жесткую связь между описанием системы и её конкретной реализацией.
Но важно учесть, что в некоторых областях, исходный функционал продукта может быть косвенно связан с технологиями, на которых планируется данный функционал реализовать.
Пример: разбиение исходной задачи на независимые этапы, которые можно легко переложить на конвейерные системы при использовании FPGA.
Один и тот же процесс можно отразить используя разные представления. Описанное в статье представление не является самым совершенным или универсальным. Оно выделяет определенные свойства для анализа.
Можно сказать, что каждое представление отсекает часть информации исходно объекта анализа. При другом анализе потребуется выделить другие свойства объекта с использованием других представлений.
У conan 2 есть как много минусов, так и много плюсов. С одной стороны, он очень гибкий, поэтому не несет в себе ровно один сценарий использования при организации своих проектов/ библиотек, с другой стороны - он показывает к чему нужно стремиться при проектировании многомодульных систем и дает все инструменты для этого.
Да и его поддерживают производители множества библиотек, т.к. выгладывают своевременно новые версии библиотек в conancenter.
Есть репы, которые аккумулируют уже созданные примеры использования.
Пример: https://github.com/Dimitrius-dev/conan2-examples
Мб кому-нибудь полезно, если хочется посмотреть именно на уже собранные шаблоны.