В программном обеспечении термин «функционал» имеет несколько определений. Институт инженеров по электротехнике и радиоэлектронике определяет термин «функционал» в IEEE 829 как «отличительную характеристику элемента программного обеспечения (например, производительность, переносимость или функциональность)».
Часть программного обеспечения считается «многофункциональной», когда она имеет много опций и функциональных возможностей, доступных пользователю.
Постепенное раскрытие — это метод, применяемый для уменьшения потенциальной путаницы, вызванной одновременным отображением множества функционала.
Иногда, если часть программного обеспечения очень многофункциональна, это можно рассматривать как плохую вещь.
Термины «расползание функционала» и «раздувание программного обеспечения» могут использоваться для обозначения программного обеспечения, которое чрезмерно многофункционально.
В компьютерном программировании функционально -ориентированное программирование (FOP) или функционально-ориентированная разработка программного обеспечения (FOSD) — это парадигма программирования для генерации программ в линейках программных продуктов (SPL) и для постепенной разработки программ.
1) Множество единиц функционала в одном проекте.
или наоборот
2) Множество проектов с одной единицей функционала.
1) Обучения.
2) Прототипирования.
3) Проектирования.
4) Кодирования.
5) Тестирования.
И так далее.
Архитектура программного обеспечения это один из слоёв конструкций, который можно выделить в коде. Другие слои могут быть шаблонами проектирования или инструкциями языка. Отличие слоя архитектуры от остальных в том, что он служит прежде всего для наращивания функционала, а не для решения иных проблем.
Таким образом идея состоит в том, чтобы отказаться от архитектуры, а сам функционал сократить до одной условной единицы демонстрирующей работу.
/*
Описание (алгоритма)
...
Образ (алгоритма)
...
Использование (алгоритма)
...
Код (алгоритма)
...
Испытание (алгоритма)
...
*/
int main(int argc, char* argv[])
{
return 0;
}
Конечно, таким способом не получить рабочий проект, ведь программа как правило не состоит из одной единицы функционала. Зато наращивание функционала становится возможным за счёт внедрения множества проектов без того, чтобы заботиться об архитектуре, ведь её нет.
1) Для создания собственных примеров работы с чужими библиотеками алгоритмов.
2) Для создания качественного рабочего прототипа алгоритма с подробным описанием и без размазывание его по коду проекта.
При запуске проекта, шаблон исходного кода, который представлен выше, можем получить следующие результаты.
+--------------------------------------+
|напечатать что-то |
| |
| |
| |
| |
| |
+--------------------------------------+
+--------------------------------------+
| нажми на меня |
+--------------------------------------+
|сделать что-то |
| |
| |
| |
+--------------------------------------+
Как видим используется наименьшее количество элементов, чего не скажешь о многофункциональном проекте.
+--------------------------------------+
|напечатать что-то напечатать что-то ^|
|напечатать что-то напечатать что-то |
|напечатать что-то напечатать что-то |
|напечатать что-то напечатать что-то #|
|напечатать что-то напечатать что-то #|
|напечатать что-то напечатать что-то v|
+--------------------------------------+
+-------------+---------+--------------+
|нажми на меня|и на меня|меня не забудь|
+-------------++--------+------+-------+
|сделать что-то|иной функционал| |
|сделать что-то| |что это|
+----+---------+---------------+-------+
|? ?|панель боинга покажется тебе раем|
+----+---------------------------------+
Здравствуйте, kov_serg, Вы писали:
_>Если вы хотите получить понимание алгоритма помимо описания и реализации (иногда нескольких с разными уровнями упрощения) нужны примеры рабочего кода с тестовыми входными и выходными данными и оценки по требуемым ресурсам.
Проблема в том, что я сначала пишу название, а потом саму статью. А затем забываю продумать и сменить название и публикую. Предыдущая статья называлась "Мобильность компьютерных устройств", а на самом деле там про
физиологию людей работающих с устройствами различной степени мобильности, что тоже сбило с толку тех, кто это прочитал.
Здесь основной смысл в единицах функционала. Тесты я перевёл как "Испытание (алгоритма)", модель как "Образ (алгоритма)". Это другая проблема, проблема именования. Однако она показывает, что любой автор, в том числе и автор фреймворка, может извращаться с названиями как хочет.
Когда дописал статью, то понял, что досокращался. В оригинале не просто комментарии, а рабочий код проекта который запускается и таких проектов множество. Думаю в реальной работе их может быть тысячи. Оттуда и взялись те же примеры однофункционального и многофункционального проекта. А это вполне себе работающие приложения с реальным кодом на Qt.
Возможно надо было написать о предпосылке, хотя я её и так знаю для каждой своей статьи, даже если и не пишу и опять же мне обычно лень дописывать. Всегда есть какая-то проблема, которую люди пытаются решить. Но рассуждая о решении они могут не упомянуть о том, что побудило их к этому.
Суть в памяти людей, в ней всё стирается, кривая забывания. Забывается не только реализация, но и сама корневая идея функционала, а так же её использование. Стоит особо отметить, что реализация может быть представлена чёрным ящиком, то есть человек может лишь догадываться как на самом деле работает алгоритм.
Здесь опять же возникает вопрос, ведь повсюду используются абстракции, они по сути и являются чёрными ящиками. Даже машинные команды это абстракции, не говоря уже о высокоуровневых инструкциях языка (язык высокого уровня абстракции), а то и вовсе нагромождение кода фреймворков.
Даже просто запуская какую-то консольную команду, или тыкая в графический интерфейс в определённой последовательности люди используют алгоритмы, это и есть использование алгоритмов. В коде программ и библиотек алгоритмов это будет вызов функций в определённых последовательностях, соединение сигналов и слотов, помещение объектов в нужные места и так далее.
Со временем человек может захотеть углубить понимание того, чем он пользуется. Хотя уже хорошо, если просто вспомнит, что функционал можно использовать в том числе и так. Всё это никак не отменяет и изучение самих алгоритмов.
Другая проблема являющаяся предпосылкой это скорость создания чего-либо. Очень печально создать что-то, но потратить на это многократно больше времени. Потому предлагается сразу писать код, а описание выполнять здесь же с помощью ascii-графики.
Объясняем код с помощью ASCII-арта.
А вот в подробности, как конкретно писать, как сшивать проекты и так далее, я не вдаюсь. Ведь это может быть любой язык программирования, любой фреймворк, собственный алгоритм, и всё, что угодно. О той же программной инженерии можно временно забыть, так как речь здесь не про неё.
Очень часто в моих рассуждениях центральной фигурой в программировании предстаёт сам человек. На него всё и завязано, лишь у него в сознании могут происходить какие-либо мысли. Но человеческое сознание не может держать все факты одновременно.
Потому именно человеку нужно давать правильные входные данные, чтобы получить правильные выходные данные. Сами же изучаемые и изменяемые системы я рассматриваю лишь как объекты с которыми работает сознание людей. И именно удобство работы с людьми нужно ставить в приоритете. Без специальных инструментов это сложно, но пока имеем то, что имеем.