Здравствуйте, velkin, Вы писали:

V>Таким образом идея состоит в том, чтобы отказаться от архитектуры, а сам функционал сократить до одной условной единицы демонстрирующей работу.
V>Описание (алгоритма)
V>Образ (алгоритма)
V>Использование (алгоритма)
V>Код (алгоритма)
V>Испытание (алгоритма)
V>Конечно, таким способом не получить рабочий проект, ведь программа как правило не состоит из одной единицы функционала. Зато наращивание функционала становится возможным за счёт внедрения множества проектов без того, чтобы заботиться об архитектуре, ведь её нет.
V>Лично я вижу применение подобного.
V>1) Для создания собственных примеров работы с чужими библиотеками алгоритмов.
V>2) Для создания качественного рабочего прототипа алгоритма с подробным описанием и без размазывание его по коду проекта.

Какая лютая каша. Если вы хотите получить понимание алгоритма помимо описания и реализации (иногда нескольких с разными уровнями упрощения) нужны примеры рабочего кода с тестовыми входными и выходными данными и оценки по требуемым ресурсам.
И потом алгоритм может использовать особенности конкретного исполнителя. Особенно для узкоспециализированных исполнителей.
А если вы хотите потом из них строить что-то как из блоков лего, то они должны иметь минимум зависимостей, и при изменениях должны поддерживать совместимость с предыдущими версиями и ряд других интересных требований которые непосредственно к блокам не относятся но всплывают при их комбинировании и эволюции.

V>Запуск проекта
V>При запуске проекта, шаблон исходного кода, который представлен выше, можем получить следующие результаты.
V>Однофункциональный проект
V>пример с выводом на консоль
V>пример с графическими элементами

Тут вообще не понятно что вы пытаетесь систематизировать. Всё зависит от модели исполнения. Последовательная, событийная, параллельная или же реалтайм (код который гарантировано запускается каждые t ms) или же вообще предобработка. Да и что бы что-то запустить нужен исполнитель и иногда среда исполнения. Например код для для дрона вы можете запустить, но без самого дрона или его симулятора и запускать будет грусно.
И комбинировать вы можете в виде нескольких суперкомбайнов или кучи узкоспециализированных утилит, выстраивая из них конвейеры.

Здравствуйте, kov_serg, Вы писали:

_>Если вы хотите получить понимание алгоритма помимо описания и реализации (иногда нескольких с разными уровнями упрощения) нужны примеры рабочего кода с тестовыми входными и выходными данными и оценки по требуемым ресурсам.

Проблема в том, что я сначала пишу название, а потом саму статью. А затем забываю продумать и сменить название и публикую. Предыдущая статья называлась "Мобильность компьютерных устройств", а на самом деле там про физиологию людей работающих с устройствами различной степени мобильности, что тоже сбило с толку тех, кто это прочитал.

Здесь основной смысл в единицах функционала. Тесты я перевёл как "Испытание (алгоритма)", модель как "Образ (алгоритма)". Это другая проблема, проблема именования. Однако она показывает, что любой автор, в том числе и автор фреймворка, может извращаться с названиями как хочет.

Когда дописал статью, то понял, что досокращался. В оригинале не просто комментарии, а рабочий код проекта который запускается и таких проектов множество. Думаю в реальной работе их может быть тысячи. Оттуда и взялись те же примеры однофункционального и многофункционального проекта. А это вполне себе работающие приложения с реальным кодом на Qt.

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

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

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

Даже просто запуская какую-то консольную команду, или тыкая в графический интерфейс в определённой последовательности люди используют алгоритмы, это и есть использование алгоритмов. В коде программ и библиотек алгоритмов это будет вызов функций в определённых последовательностях, соединение сигналов и слотов, помещение объектов в нужные места и так далее.

Со временем человек может захотеть углубить понимание того, чем он пользуется. Хотя уже хорошо, если просто вспомнит, что функционал можно использовать в том числе и так. Всё это никак не отменяет и изучение самих алгоритмов.

Другая проблема являющаяся предпосылкой это скорость создания чего-либо. Очень печально создать что-то, но потратить на это многократно больше времени. Потому предлагается сразу писать код, а описание выполнять здесь же с помощью ascii-графики. Объясняем код с помощью ASCII-арта.

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

Очень часто в моих рассуждениях центральной фигурой в программировании предстаёт сам человек. На него всё и завязано, лишь у него в сознании могут происходить какие-либо мысли. Но человеческое сознание не может держать все факты одновременно.

Потому именно человеку нужно давать правильные входные данные, чтобы получить правильные выходные данные. Сами же изучаемые и изменяемые системы я рассматриваю лишь как объекты с которыми работает сознание людей. И именно удобство работы с людьми нужно ставить в приоритете. Без специальных инструментов это сложно, но пока имеем то, что имеем.