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

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

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

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

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

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

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

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

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

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

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

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

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

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