Как я понял по вики, методологии – это классификации парадигм, но какой либо чёткой связи между ними не вижу, и всё это под соусом моделей, подходов/приёмов, направлений, концепций, и остальной мутотени... Как чёрт побери в этом разобратья?!
По вики ничего никогда не поймёте.
Для того, чтобы что-то понять, нужно это обобщить.
Хотите понять процедурную парадигму, напишите несколько программ на ассемблере. Хотите понять структурную парадигму, напишите несколько программ на Си. Хотите понять функциональную, ООП - напишите. Когда поймёте, сравните парадигмы, как одни и те же концепции будут выглядеть в разных парадигмах. Вот в этот момент вы поймёте, что такое парадигма. Почему важно оставаться в рамках парадигмы и всю важность четко сформулированнвх термнов.
То же самое с методологиями разработки.
Попробуйте одну, вторую, третюю, обобщите, сравните.
Википедия - это не обучающий ресурс, а справочник, в котором без понимания вы видите буквы и слова, а не термины и суть.
Sozdatel_Nichego, нет, чтобы понять абстракцию, нужно обобщить свой опыт, и его получить можно только, если писать код. Формальный ответ на ваш вопрос звучит так: парадигма объявляет термины в каком-то контексте, а методология вводит абстракции и их правила взаимодействия с ними для определенного контекста. Но такой ответ нельзя назвать понятным.
Sozdatel_Nichego, пожалуйста, по-конкретнее укажите на то, что вас смущает, чтобы я мог скорректировать ответ и дать пояснения.
Vito Ombero, ну, допустим, я написал игру с тысячами зомби, в виде одно класса. Что и когда здесь методология, или парадигма?
Если методология – это поведение абстракций, то это класс? А парадигма объясняет это поведение?
Sozdatel_Nichego, в таком случае, использованной вами методологией организации разработки ПО будет скорее всего водопад, т.к. у вас весь код есть монолит и он не может быть разбит на модули. Термин обычно не используют для контекстов, где человек не является субъектом, для методологии человек всегда субъект и использует методологию для достижения целей.
Методологией конструирования кода будет приоритет оптимизации над внесением изменений, т.к. иных объективных причин не использовать инструментарий компилятора - классы - быть не может.
Какие парадигмы вы будете использовать во время написания кода зависит только от выбора конкретного способа отображения абстракции или поведения в коде. Если вы не используете классы и язык предоставляет инструменты для обращения к памяти через указатели, то вы можете использовать ООП, если захотите, просто вам придется реализовывать концепции самостоятельно и вы будете проводить статический анализ самостоятельно вместо компилятора. Зато вы получите гибкость в нужных местах, поскольку сможете нарушать парадигмы ООП в любом месте на любом этапе жизни объекта, за счёт дикой оптимизации, например на инициализации объектов классов и освобождении памяти из пула, над которым вы имеете полный контроль. Вы можете делать небезопасные преобразования типов, просто через указатели и расположение полей, вместо апкастов и даункастов, вы можете использовать знание о том, какого класса и с какими значениями полей был объект, когда его уничтожили, для того, чтобы переиспользовать память и сэкономить несколько спичек во время инициализации объекта другого класса или со схожими значениями полей.
Ваши абстракции скорее всего будут выражены в комментариях, а не в локализованных участках кода, инварианты вообще не будут практически никак не отображены, и логика для каждой абстракции игровой модели будет действительно размазана по всему коду.
Вы не будете использовать общепринятые практики конструирования ПО, и ваш код будет мало понятен другим людям, т. к. очень много вещей не будут выражены непосредственно явно выражены в коде.
Но если ТЗ гарантировано неизменно, то вы с таким подходом уместитесь в память, но разработка будет вестись очень долго, а тестирование будет невозможно автоматизировать.
Предисловие. Upd: В вики написано, что водопад — это метод. Upd: Я совсем забыл, что недавно сам придумал, как разделять работу: Относительно цели (хлеба), подход — достижение цели (поход в магазин до хлеба), а метод — способ реализации цели (поход домой до съедения хлеба). Upd: Наши мысли немного пересекаются. Upd: Оказывается, понятие методологии очень сильно связано с алгоритмами в математике… Но я не сверхмозг, извините.
Я выделил ваши ключевые положения, связал их, и сопоставил с понятиями у меня и из вики:
[методологии] Методологией конструирования кода будет приоритет оптимизации над внесением изменений, т.к. иных объективных причин не использовать инструментарий компилятора - классы - быть не может. Пс: Это воспроизведённые, то бишь эмуляция сущностей (система), упрощение API (как формул в мате. Метод).
[парадигмы] Какие парадигмы вы будете использовать во время написания кода зависит только от выбора конкретного способа отображения абстракции или поведения в коде. Пс: Это воспроизведение, то бишь симуляция системы (сущностей) API, ручным способом (Подход).
Ниже вы размышляете про [низы] (Си), наверное хотите вдохновить меня, в детали. Как я понял, всё программирование — это не готовые решения, а костыли, то бишь парадигмы. Можно подключить к си опенгл, и создать функциями работу со списками-массивами, как в питоне. И так можно сделать уже любое медиаприложение))) Но через тома кода.
Вопщем за этими терминами стоят конкретные мотивы (на эмоциональном плане, это не математические абстракции:), но остальное уже философия, я сворачиваюсь.
