Comments 7
Вы шаг за шагом отсекаете альтернативные варианты решения, загоняя себя в туннельное мышление, шаблон. Так и было задумано?
Можно измыслить мир процессами и состояниями. А можно фактами и их связями.
Крокодил не видит то, что не движется. Бабочка видит неподвижный цветок в деталях.
Один и тот же процесс можно отразить используя разные представления. Описанное в статье представление не является самым совершенным или универсальным. Оно выделяет определенные свойства для анализа.
Можно сказать, что каждое представление отсекает часть информации исходно объекта анализа. При другом анализе потребуется выделить другие свойства объекта с использованием других представлений.
теги: программирование, проектирование, оптимизация, разработка по
В тексте 0 строк кода.
Согласен, что некоторые теги, которые обычно ассоциируют с представлением реализации на определенном ЯП, могут немного запутать читателя. С другой стороны, проектирование программного продукта часто занимает высший приоритет, т.к. в современных системах стараются не делать жесткую связь между описанием системы и её конкретной реализацией.
Но важно учесть, что в некоторых областях, исходный функционал продукта может быть косвенно связан с технологиями, на которых планируется данный функционал реализовать.
Пример: разбиение исходной задачи на независимые этапы, которые можно легко переложить на конвейерные системы при использовании FPGA.
А слабо ответить, не подключая llm?
По сути:
проектирование программного продукта часто занимает высший приоритет, т.к. в современных системах стараются не делать жесткую связь между описанием системы и её конкретной реализацией.
Это не причина и следствие. Да, высший приоритет, нет это не имеет отношение к связи между описанием и реализацией. Проектирование опирается на возможности стека. Есть задачи, которые язык решает хорошо и есть парадигмы, в которых язык хорошо работает. Поэтому, писать статью по дизайну/архитектуре, не используя псевдокод в этой парадигме - это вода и спекуляции.
Забавно, если стиль моего ответа на комментарий показался результатом llm, но нет - все писалось ручками.
Согласен, с псевдокодом было бы легче соотнести описание с реальным кодом. Но существует еще и визуальное проектирование (те же диаграммы UML), грубо говоря, описанные в статье сущности можно представить в контексте объектно-ориентированного стиля отдельными классами с агрегацией экземпляров других классов.
"По стилю изложения текст напоминает псевдонауку, но именно этот стиль мне кажется наиболее подходящим для ..." Для псевдоначных умствований?
Ценность модели определяется широтой и сложностью задач, которые могут быть решены с ее помощью. Например, при помощи трех законов Ньютона можно решить бесчисленное количество механических задач. При помощи небольшого набора аксиом можно решать огромное количество геометрических задач.
А какие задачи можно решить при помощи ваших измышлений? Задачу описания "чего угодно"? Ну, так с этим прекрасно справляются естественные языки, в частности, русский на котором написана эта статья.
Интерфейсное проектирование в абстрактных системах