Недостатки ООП, DDD (Domain-driven design) и паттернов. Альтернатива ООП

Привет, Вы узнаете о том , что такое недостатки ооп, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое недостатки ооп, альтернатива ооп, ddd, архитектура программного обеспечения , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

Объектно-ориентированные программы предлагаются в качестве альтернативы правильным.

Эдсгер В. Дейкстра, пионер информатики

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

«Объектно-ориентированные программы предложены как альтернатива правильным...»

– Эдсгер Вибе Дейкстра, один из разработчиков концепции структурного программирования.

Объектно-ориентированное программирование создавалось с одной целью: управление сложностью процедурного кода. Другими словами, оно должно было улучшить организацию кода. Между тем, не существует объективного и открытого доказательства превосходства ООП над чистым процедурным программированием.

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

Многие не согласятся, но правда в том, что современное ООП никогда не разрабатывалось правильно. Оно никогда не опиралось на правильные исследовательские институты (в отличие от Haskell/FP). У ООП нет десятилетий строгих научных исследований. Лямбда-исчисления предлагают полную теоретическую основу для функционального программирования. У ООП нет ничего близкого к этому. По большому счету, ООП «просто случилось».

ООП-код недетерминированный, в отличие от функционального программирования нам не гарантирован одинаковый вывод при одном и том же вводе. В качестве упрощенного примера: 2 + 2 или calculator.Add(2, 2) дают на выходе 4, но иногда могу дать 3, 5 или вообще 1004. Зависимости объекта Calculator могут менять результат вычислений в тонкой, но глубокой манере.

Объектно-ориентированное программирование кажется стандартной, самой распространенной парадигмой проектирования ПО. Именно его обычно преподают студентам, объясняют в онлайн-туториалах и, по какой-то причине, спонтанно применяют даже тогда, когда не собирались этого делать.

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

Вспомним что такое ООП, которому уже более 50 лет.

Тимоти Бадд пишет:

Роджер Кинг аргументированно настаивал, что его кот является объектно-ориентированным. Кроме прочих своих достоинств, кот демонстрирует характерное поведение, реагирует на сообщения, наделен унаследованными реакциями и управляет своим, вполне независимым, внутренним состоянием.

По мнению Алана Кэя, создателя языка Smalltalk, которого считают одним из «отцов-основателей» ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов (цитируется по вышеупомянутой книге Т. Бадда).

1. Все является объектом.
2. Вычисления осуществляются путем взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия.
3. Каждый объект имеет независимую память, которая состоит из других объектов.
4. Каждый объект является представителем класса, который выражает общие свойства объектов (таких, как целые числа или списки).
5. В классе задается поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.
6. Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определенного класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.

Таким образом, программа представляет собой набор объектов, имеющих состояние и поведение. Объекты взаимодействуют посредством сообщений.

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

«Мне очень жаль, что я давно ввел термин "объекты" для этой темы, потому что он заставляет многих людей сосредоточиться на меньшей идее. Основная идея – обмен сообщениями.» – Алан Кэй, один из пионеров в областях объектно-ориентированного программирования.

Алан Кэй придумал термин «Объектно-ориентированное программирование» а 1960х. Благодаря своему биологическому бэкграунду он пытался создать коммуникацию между компьютерными программами по подобию живых клеток.

Основная идея Алана Кэя состояла в коммуникации между независимыми программами (клетками). Состояние независимых программ никогда не раскрывалось внешнему миру (инкапсуляция).

Вот и все. ООП никогда не было предназначено для таких вещей, как наследование, полиморфизм, ключевого слова «new» и несчетного количества шаблонов проектирования.

Необходимость в гибком фреймворке

«C++ – ужасный [объектно-ориентированный] язык... Ограничение вашего проекта до C означает, что люди не облажаются с какой-нибудь идиотской "объектной моделью"c&@p.» – Линус Торвальдс, создатель Linux.

Линус Торвальдс известен своей критикой в адрес C++ и ООП. Он прав в ограничении программистов. Чем меньше выбора у программиста, тем гибче становится его код. В цитате выше Линус Торвальдс настоятельно рекомендует использовать хороший фреймворк как базу для кода.

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

Хороший фреймворк помогает писать надежный код. Он должен помогать снижать сложность с помощью:

1. Модульности и повторного использования.
2. Правильной изоляции состояний.
3. Высокого отношения сигнал/шум.

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

Данные важнее, чем код

Еслибы вы были владельцем проекта ,то как бы вы ранжировали(упорядочили ) такие понятия для вашего проекта?

• a) максимальное соотвествие функционала (фич) заданных в спецификации (техническом задании) и ожиданиям маркетологов
• b) максималлнная надежности и минимум багов
• c) обманчивания хорошая расширяемость приложеения в будущем но с ущербом по срокам в аазработке(обманчивая- потомучто требуется постоянный рефакторинг)
• d) максималная атомизация кода на классы, интерфейсы , мметоды домены
• e) максимальная академическая грамотность при применениии различных методик проектирования (ООП, функционанльного, DDD), использования паттернов

Для классичческого ООП будет примерно такая последовательность и важность

1 место e)

2 место d)

3 место c)

4 место b)

5 место a)

Взляните на эту иерархию(примечание, нельзя на одном месте ставить несколко понятий), вы заметили что при слепом применении ООП вы просто плюете на саму идею приложения и заказчика? теперь задумайтесь нужно ли слепо применять ООП и все ли у него хорошо?

Ктому не следует забывать что все императивные языки программирования и парадигмы (включая ООП) более примитивные по сравнению с декларативным программированием (включая Языково-ориентированное программирование, DSL-Based Development, предметно-ориентированных языков ) Примерами языков и парадигм с более высоким уровнем и более современными являются функциональные языки программирования, SQL, логически язык програмрования, и даже HTML и множестро где программист не забымывается как будет делать а заказывает что хочет получит и получает. Приэтом не следует путать эти парадигмы с одноименными стилями программрования.

Рисунок 1 Сравнение императивного и декларативного программирования

По своей сути все ПО предназначено для манипуляций данными с целью достижения определенного результата. Результат определяет способ структурирования данных, а структура данных определяет необходимый код.Но не наоборот. Тоесть нет смысла пложить бесконечное количество строк кода, беспонечное количество классов. Чем больше классов тем сложненее понимание всей архитектуры приложение , уменшение его надежности, усложнение тестированности, появление большео количества баов и значительное увеличесние времени на разработу и времени выполнения таких программ т к для их выполнения требуется большего количества ресурсов.

Рисунок 2 Классификация парадигм программирования

Этот момент очень важен, так что я повторюсь: цель -> архитектура данных -> код. Здесь порядок менять ни в коем случае нельзя! При проектировании программы нужно всегда начинать с выяснения цели, которой нужно достичь, а затем хотя бы приблизительно представить архитектуру данных: структуры и инфраструктуру данных, необходимые для ее эффективного достижения. И только после этого нужно писать код для работы с такой архитектурой. Если со временем цель меняется, то нужно сначала изменить архитектуру данных, а потом код.

По моему опыту, самая серьезная проблема ООП заключается в том, что оно мотивирует игнорировать архитектуру модели данных и применять бестолковый паттерн сохранения всего в объекты, обещающие некие расплывчатые преимущества. Если это подходит для класса, то это отправляется в класс. У меня есть Customer? Он отправляется в class Customer. У меня есть контекст рендеринга? Он отправляется class RenderingContext.

Вместо построения хорошей архитектуры данных внимание разработчика смещено в сторону изобретения «хороших» классов, взаимосвязей между ними, таксономий, иерархий наследования и так далее. Это не просто бесполезное занятие. В глубине своей оно очень вредно.

Таблица 1 Сравненине процедурного, ооп и функционального программирования.

Таблицу 1 конечно желательно расширить, добавив логическое программирование, SQL, и программирование на основе нейросетей, программрование на основе кубитов.

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

Критические высказывания в адрес ООП:

• Было показано отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом[Thomas E. Potok, Mladen Vouk, Andy Rindos. Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment (англ.) // Software – Practice and Experience. — 1999. — Vol. 29, no. 10. — P. 833—847.].
• Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП[ C. J. Date, Introduction to Database Systems, 6th-ed., Page 650].
• Александр Степанов в одном из своих интервью указывал, что ООП «методологически неправильно» и что «…ООП практически такая же мистификация, как и искусственный интеллект…»[ STLport: An Interview with A. Stepanov].
• Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесенную сложность в выражение дизайна. Дизайн остается сложным по своей природе…» .
• Эдсгер Дейкстра указывал: «…то, о чем общество в большинстве случаев просит — это эликсир от всех болезней. Естественно, „эликсир“ имеет очень впечатляющие названия, иначе будет очень трудно что-то продать: „Структурный анализ и Дизайн“, „Программная инженерия“, „Модели зрелости“, „Управляющие информационные системы“ (Management Information Systems), „Интегрированные среды поддержки проектов“, „Объектная ориентированность“, „Реинжиниринг бизнес-процессов“…» .
• Никлаус Вирт считает, что ООП — не более чем тривиальная надстройка над структурным программированием , и преувеличение ее значимости, выражающееся, в том числе, во включении в языки программирования все новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
• Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «…ООП предоставляет вам множество способов замедлить работу ваших программ…».
• Известная обзорная статья проблем современного ООП-программирования перечисляет некоторые типичные проблемы ООП
• В программистском фольклоре получила широкое распространение критика объектно-ориентированного подхода в сравнении с функциональным подходом с использованием метафоры «Королевства Существительных» из эссе Стива Йегги.

Гради Буч указывает на следующие причины, приводящие к снижению производительности программ из-за использования объектно-ориентированных средств:

Динамическое связывание методов

Обеспечение полиморфного поведения объектов приводит к необходимости связывать методы, вызываемые программой (то есть определять, какой конкретно метод будет вызываться) не на этапе компиляции, а в процессе исполнения программы, на что тратится дополнительное время. При этом реально динамическое связывание требуется не более чем для 20 % вызовов, но некоторые ООП-языки используют его постоянно.

Значительная глубина абстракции

ООП-разработка часто приводит к созданию «многослойных» приложений, где выполнение объектом требуемого действия сводится к множеству обращений к объектам более низкого уровня. В таком приложении происходит очень много вызовов методов и возвратов из методов, что, естественно, сказывается на производительности.

Наследование «размывает» код

Код, относящийся к «конечным» классам иерархии наследования, которые обычно и используются программой непосредственно, находится не только в самих этих классах, но и в их классах-предках. Относящиеся к одному классу методы фактически описываются в разных классах. Это приводит к двум неприятным моментам:

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

Инкапсуляция снижает скорость доступа к данным

Запрет на прямой доступ к полям класса извне приводит к необходимости создания и использования методов доступа. И написание, и компиляция, и исполнение методов доступа сопряжены с дополнительными расходами.

Динамическое создание и уничтожение объектов

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

Если попытаться классифицировать критические высказывания в адрес ООП, можно выделить несколько аспектов критики данного подхода к программированию.

Критика рекламы ООП

Критикуется явно высказываемое или подразумеваемое в работах некоторых пропагандистов ООП, а также в рекламных материалах «объектно-ориентированных» средств разработки представление об объектном программировании как о некоем всемогущем подходе, который магическим образом устраняет сложность программирования. Как замечали многие, в том числе упомянутые выше Брукс и Дейкстра, «серебряной пули не существует» — независимо от того, какой парадигмы программирования придерживается разработчик, создание нетривиальной сложной программной системы всегда сопряжено со значительными затратами интеллектуальных ресурсов и времени. Из наиболее квалифицированных специалистов в области ООП никто, как правило, не отрицает справедливость критики этого типа.

Оспаривание эффективности разработки методами ООП

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

Производительность объектно-ориентированных программ

Указывается на то, что целый ряд «врожденных особенностей» ООП-технологии делает построенные на ее основе программы технически менее эффективными, по сравнению с аналогичными необъектными программами. Не отрицая действительно имеющихся дополнительных накладных расходов на организацию работы ООП-программ (см. раздел «Производительность» выше), однако значение снижения производительности часто преувеличивается критиками. В современных условиях, когда технические возможности компьютеров чрезвычайно велики и постоянно растут, для большинства прикладных программ техническая эффективность оказывается менее существенна, чем функциональность, скорость разработки и сопровождаемость. Лишь для некоторого, очень ограниченного класса программ (ПО встроенных систем, драйверы устройств, низкоуровневая часть системного ПО, научное ПО) производительность остается критическим фактором.

Критика отдельных технологических решений в ООП-языках и библиотеках

Эта критика многочисленна, но затрагивает она не ООП как таковое, а приемлемость и применимость в конкретных случаях тех или иных реализаций ее механизмов. Одним из излюбленных объектов критики является язык C++, входящий в число наиболее распространенных промышленных ООП-языков.

Недостатки объектно-ориентированного проектирования и программирования

1. Документирование классов — ресурсоемкая задача.

2. Резко увеличивается время на анализ и проектирование систем

3. Увеличение времени выполнения.

4. Неэффективность на этапе выполнения.

5. Размер кода увеличивается

6. Неэффективно с точки зрения памяти (мертвый код - тот, который не используется)

7. Сложность распределения работ на начальном этапе и при изменении архитектуры и функционала

8. В сложных иерархиях классов поля и методы обычно наследуются с разных уровней. И не всегда легко определить, какие поля и методы фактически относятся к данному классу. Для получения такой информации нужны специальные инструменты, вроде навигаторов классов.
9. Методы, как правило, короче процедур, зато их намного больше. В коротких методах легче разобраться, но они неудобны тем, что код для обработки сообщения иногда «размазан» по многим маленьким методам
10. Необходимо понимать базовые концепции, такие как классы, наследование и динамическое связывание.
11. Многоразовое использование требует от программиста познакомиться с большими библиотеками классов.
12. Проектирование классов — задача куда более сложная, чем их использование. Очень трудно изучать классы, не имея возможности их «пощупать».
13. ООП порождает огромные иерархии классов, что приводит к тому, что функциональность расползается или, как говорят, размывается по базовым и производным членам класса, и отследить логику работы того или иного метода становится сложно.
14. В некоторых языках все данные являются объектами, в том числе и элементарные типы, а это не может не приводить к дополнительным расходам памяти и процессорного времени.
15. Также, на скорости выполнения программ может неблагоприятно сказаться реализация полиморфизма, которая основана на механизмах позднего связывания вызова метода с конкретной его реализацией в одном из производных классов.
16. Психологический аспект. Многие считают, что ООП это круто и начинают использовать его подходы всегда и везде и без разбору. Все это приводит к снижению производительности программ в частности и дискредитации ООП в целом.
17. Документирование классов - задача более трудная, чем это было в случае процедур и модулей. Поскольку любой метод может быть переопределен, в документации должно говориться не только о том, что делает данный метод, но и в каком контексте он вызывается.
18. В сложных иерархиях классов поля и методы обычно наследуются с разных уровней. Не всегда легко определить, какие поля и методы фактически относятся к данному классу. Если класс расширяется, то каждый метод обычно сокращают перед передачей сообщения базовому классу. Реализация операции, таким образом, рассредоточивается по нескольким классам, и чтобы понять, как она работает, приходится внимательно просматривать весь код.
19. Методы, как правило, короче процедур, поскольку они осуществляют только одну операцию над данными, зато их намного больше. В коротких методах легче разобраться, но они неудобны тем, что код для обработки сообщения иногда "размазан" по многим маленьким методам.
20. Инкапсуляцией данных не следует злоупотреблять. Чем больше логики и данных скрыто в недрах класса, тем сложнее его расширять. Отправной точкой здесь должно быть не то, что клиентам не разрешается знать о тех или иных данных, а то, что клиентам для работы с классом этих данных знать не требуется.
21. Снижение быстродействия программы, связанное с использованием виртуальных методов;
22. Идеи ООП не просты для понимания и в особенности для практического использования;
23. Для эффективного использования существующих ОО систем требуется большой объем первоначальных знаний, умений и навыков.
24. Злоупотребление инкапсуляцией данных. Чем больше логики и данных скрыто в недрах класса, тем сложнее его расширять.
25. Неэффективность на этапе выполнения, в т.ч. инкапсуляция данных.
26. Неэффективность в смысле распределения памяти. Излишняя универсальность
27. Существенное влияние ограничений и условностей языков программирования (в первую очередь C++ и Java)
28. Ориентированность ООД(объектно-ориентированный дизайн ) на простейшую реализацию объектной модели
29. Невозможность во многих случаях соблюдения собственных принципов
30. Как следствие – необходимость использования большого количества точечных решений, как например GOF-patterns

31. Проблемы параллелизма Беспорядочное совместное использование изменяемого состояния в ООП делает распараллеливание такого кода практически невозможным. Для решения этой проблемы были изобретены сложные механизмы: блокировка потоков, мьютекс и многие другие. У таких сложных подходов есть свои недостатки — взаимоблокировки, отсутствие возможности компоновки, плюс отладка многопоточного кода очень сложна и отнимает много времени. Речь даже не идет об увеличении сложности, вызванном использованием таких механизмов параллелизма.

32. Много кода. Программисты настолько привыкли к ООП, что пишут на нем все задачи. Возьмем ту же знакомую нам регистрацию пользователя. Для этого пишут класс, в нем свойства, конструктор, функцию, которая содержит код обработки формы и запись данных пользователя в базу. Потом создают экземпляр класса, и через него вызывают функцию. Чуть ниже мы показываем решения этой задачи на ООП, а трак же руками программиста.
33. Очень много действий. Как бы Вы не старались писать чище скрипт, используя ООП, Паттерны, Фремворки , интерпретатору приходится выполнять очень много лишних операций, при этом значительно возрастают накладные расходы.
34. Время интерпретации проекта на ООП с использованием паттерном и фремворков больше в сотни раз, чем проект на чистом коде, но конечно чисты код нужно применять тоже разумно. Чем больше действий - тем больше времени надо, для их совершения и обработки. На это влияет обьем скриптов, и количество действий, т.к. сервер израсходует время на загрузку тяжелого файла ООП в оперативную память, синтаксический анализ и выполнение. Все последние версии готовых CMS и фреймворков используют PDO, для подключения к базе. Если углубится, то можно выяснить, что по времени одно подключение к сторонней базе равно времени обработки проекта на чистом коде.
35. Неэффективно с точки зрения оперативной памяти сервера. Оперативки на сервере ООП "сьедает" в сотни (самый простой проект на ООП), а то и тысячи раз больше (фреймворк, и темболее CMS) по сравнении с проектом на чистом коде. Да именно на этом наживаются все хостинги, и и те кто предосталяет облачные услуги типа Амазон AWZ и тд
36. Незадействанный лишний код. Любой проект, написанный на ООП имеет частично ии послностью мервый код. Приведу пример ООП класса репозитория продавцоы, в котором есть такие функции: получить всех продавцов, получить конкретного продавца, получить продавцов по фильтру... Если нужно показать конкретного продавца, отработает метод, отвечающая за это, в то же время другие методы будут незадействованы, что очень нехорошо.
37. Подход ООП делает путаницу в коде. Любая CMS-система, фреймворк, шаблон проектирования настолько запутаны имет большую связность и зацепление, что можно зарости как обезьяна, пытаясь разобрать каждую строку кода, что за что отвечает.
38. ООП - это небезопасно, поскольку 95% программистов пользуются готовыми паттернами, вендорами, фреймворками и тем более CMS, а они все широко распространяются в открытом интернете. то хакеру не составит никакого труда найти "дырку" в коде и произвести взлом.

Проекты которые проигрывают в конкуренции или обонкротились или

продолжение следует...

Продолжение:

Часть 1 Недостатки ООП, DDD (Domain-driven design) и паттернов. Альтернатива ООП
Часть 2 Какие же есть решения проблем ООП? - Недостатки ООП, DDD
Часть 3 Имитация Сложности - Недостатки ООП, DDD (Domain-driven design) и паттернов.
Часть 4 Архитектурные шаблоны - Недостатки ООП, DDD (Domain-driven design) и паттернов.

См.также

• покер планирования ,
• скрам-мастер и тамада ,
• ddd , bdd ,
• DDD отзывы, или что вы думаете о Domain-driven design
  
• чистая архитектура ,
• чистая архитектура и ddd ,
• Модель жизненного цикла
• гибкая методология разработки , agile-методы ,
• структурное программирование ,
• двумерное структурное программирование , структурное программирование ,
• процедурное алгоритмическое программирование ,
• логическое программирование ,
• стили программирования , парадигмы программирования ,
• объектно-ориентированное программирование , введение в ооп ,
• функциональное программирование , замыкание ,
• фреймворк , классификация фреймворков ,
• языки программирования ,
• уровни языков программирования , эволюция языков ,
• тестирование по
• разработка по
• качество по
• производитеьность по
• надежность по

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