Достоинства и недостатки ооп кратко

Обновлено: 02.07.2024

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

Прототипные языки программирования

Императивная парадигма, где реализация программного продукта осуществляется за счет оперирования иерархиями объектов. Это полезно для компактных программ с небольшим объёмом кода.

Самая известная реализация прототипной спецификации ECMAScript — язык JavaScript. Традиционная его ниша — фронтенд. Но с недавних пор ведётся также активная разработка на этом языке и бэкенд-решений.

Вот как выглядит поиск по вакансиям программистов на прототипных языках:

JavaScript — 16 603;
Node.js — 1 403;
Slate — 9;
Agora — 3;
Cecil — 0.

Функциональные языки программирования

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

Haskell применяется в финансовом программировании, при анализе рисков, в системах поддержки принятия решений. Erlang применяется в телекоммуникациях.

Смотрим вакансии (кстати, уровень зарплаты по ним выше среднего):

Haskell — 71;
Erlang — 70;
Lisp — 10.

Объектно-ориентированное программирование

Императивная парадигма, где реализация программного продукта осуществляется за счёт оперирования иерархиями классов и объектов. Базируется на таких подходах, как полиморфизм, инкапсуляция, абстракция и наследование.

Всё построено на повторном использовании кода, что ускоряет разработку. Кроме того, найти программистов на ООП несложно, потому что это очень развитый рынок — и в продуктовом, и в HR-смыслах. Это хорошо видно по количеству вакансий:

Java — 12 346;
PHP — 7 159;
C++ — 5 795;
Kotlin — 3 049.

ООП используется при написании операционных систем, СУБД, компиляторов, драйверов, множества прикладных программ. Например, достаточно сказать, что почти все известные браузеры, Microsoft Office, Adobe Photoshop и Illustrator — продукты объектно-ориентированного программирования.

Похоже, его рано списывать со счетов. Однако многие критикуют ООП. Какие претензии предъявляют очевидному лидеру, чем он не угодил?

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

ООП не раз подвергалось критике. Одно из самых ярких обвинений прозвучало от британского программиста — Джо Армстронга.

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

Это во многом справедливо. Помимо недостаточно качественной поддержки параллельных и распределенных систем, ООП отличается относительно низким качеством конечного продукта.

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

ООП предоставляет вам множество способов замедлить работу ваших программ.

Как же получилось, что такой уязвимый, избыточный, громоздкий подход к программированию стал основным в глобальном масштабе и до сих пор сохранил свои позиции?

Преимущества объектно-ориентированного программирования

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

По мере того, как наперегонки развивались Hardware и Software, объёмы исходных кодов в программах начали стремительно расти. Теперь для его поддержки уже требовалась определенная архитектура. Стали применяться различные подходы к оформлению исходных кодов, и в конечном счёте появились парадигмы программирования. ООП выделялось сразу несколькими критично важными отличиями:

Повторяемость кода ООП привела к созданию библиотек классов. Можно тратить всё меньше времени на получение уже полученных ранее результатов — причём даже не очень важно, кем именно и на каких проектах были сделаны прежние разработки. Так и начал формироваться парадокс банана: с одной стороны — упрощение разработки за счёт тиражирования уже реализованных классов. С другой — неоптимальное использование аппаратных ресурсов.

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

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

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

Резюме

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

Конечно, пропорции в разработке будут меняться. Это уже происходит. Кроме того, рано или поздно появятся принципиально другие, новые подходы — и они могут оказаться недостижимо более производительными, особенно на модернизированном железе.

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

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

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

Полиморфизм оказывается полезным преимущественно в следующих ситуациях:

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

Изменение поведения во время исполнения. На этапе исполнения один объект может быть заменен другим, что позволяет легко без изменения кода адаптировать алгоритм, в зависимости от того, какой используется объект.
Реализация работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.
Создание “каркаса” ( framework ).

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

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

Сокращается время на разработку, которое с выгодой может быть отдано другим задачам.

Компоненты многоразового использования обычно содержат гораздо меньше ошибок,

чем вновь разработанные, ведь они уже не раз подвергались проверке.

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

Недостатки ООП

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

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

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

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

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

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

Полиморфизм оказывается полезным преимущественно в следующих ситуациях.

Обработка разнородных структур данных. Программы могут работать, не различая вида объектов , что существенно упрощает код. Новые виды могут быть добавлены в любой момент.
Изменение поведения во время исполнения. На этапе исполнения один объект может быть заменен другим, что позволяет легко, без изменения кода, адаптировать алгоритм в зависимости от того, какой используется объект .
Реализация работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов .
Создание "каркаса" (framework). Независимые от приложения части предметной области могут быть реализованы в виде набора универсальных классов , или каркаса (framework), и в дальнейшем расширены за счет добавления частей, специфичных для конкретного приложения.

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

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

Недостатки ООП

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

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

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

Излишняя универсальность. Неэффективность также может означать, что в программе реализованы избыточные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, они становятся мертвым грузом. Это не влияет на время выполнения, но сказывается на размере кода.

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

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

Заключение

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

Рассказываю об одной из важнейших парадигм в программировании.

Парадигмы программирования и их виды

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

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

Что такое ООП?

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

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

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

Структура объектно-ориентированного программирования

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

Объекты

И хотя в структуре ООП объекты находятся не на первом месте, мы начнем с них, так как это упрощает общее понимание парадигмы.

Объект – это кусок кода, описывающий элемент с конкретным набором характеристик и функций. Например, вы делаете видеоигру, в которой есть персонаж. Ваш герой.

Этот персонаж в коде может быть отдельным объектом с такими характеристиками, как здоровье, сила, выносливость, ловкость и урон, а также функциями (методами) – это могут быть магические способности или особые приемы, используемые персонажем.

Объекты могут описывать других персонажей и средства передвижения.

Методы

Атрибуты

Атрибуты – это конкретные характеристики объекта. Если вы хоть немного знакомы с программированием, то атрибуты можно представить в виде переменных с данными. Вернувшись к примеру с игровым персонажем, в качестве атрибутов можно представить характеристики в духе уровня выносливости, скорости и других статических показателей.

Классы

Это наиболее абстрактная и обобщенная форма в ООП. Что-то в духе шаблона, на базе которого строятся другие элементы структуры кода.

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

Поэтому мы можем создать класс – то есть объект, способный стать базой для других объектов. Например, класс – персонаж. Он умеет ходить, драться, имеет характеристики наподобие уровня здоровья или количества маны, то есть атрибуты, что есть у любых рас и классов в нашей РПГ. А уже человек-воин (объект) с ником Nagibator777 будет содержать более специфичные характеристики и методы, зависящие от решений игрока и других внешних факторов. Класс – это пример абстракции и наследования, упрощающий генерацию новых объектов.

На картинках и схемах эта структура выглядит куда понятнее.

Ключевые принципы ООП

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

Инкапсуляция

Этот принцип гласит, что вся важная информация, необходимая для работы объекта, в нем же и хранится. И только определенные данные доступны для внешних функций и объектов.

Такой подход обеспечивает повышенный уровень безопасности, а также сокращает шансы на случайное повреждение данных внутри какого-то класса или объекта со стороны.

Наследование

Это как раз основная суть взаимоотношений между классами и объектами, описанная выше. Чтобы не создавать кучу одинаковых объектов или классов, можно создать класс над классами с более общими характеристики и функциями, а потом постепенно наследовать от него те или иные возможности. Используя специальную конструкцию, программист может забрать из класса ряд атрибутов или методов, оставить их в прежнем виде и дополнить новыми или же слегка переосмыслить на свое усмотрение, а потом создать из них уникальный объект или подкласс для дальнейшего наследования опций.

Это проще понять на примере со средствами передвижения:

Не нужно каждый раз создавать новый класс или объект с полным набором опций. Достаточно воспользоваться конструкцией в духе export class Bus extends Vehicle() и дополнить код конкретикой.

Абстракция

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

Полиморфизм

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

Преимущества ООП

Основными преимуществами парадигмы разработчики считают следующие особенности:

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

Реюзабельность кода: благодаря абстракциям, полиморфизму и наследованиям можно не писать один и тот же код много раз, что заметно ускоряет создание нового ПО.

Высокая скорость разработки: классы и интерфейсы в ООП могут легко трансформироваться в подобие полноценных библиотек, которые можно переиспользовать в новых проектах.

Расширяемость: ООП-код легче развивать, дополнять и менять. Этому способствует независимая модульная структура.

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

Гибкость: полиморфизм позволяет быстро адаптировать ООП-код под свои нужды, не описывая новые функции и объекты.

Недостатки ООП

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

Языки, исповедующие объектно-ориентированную парадигму

Существует множество языков программирования, подходящих для применения ООП-парадигмы. Среди них:

Ruby – высокоуровневый язык с динамической типизацией, созданный в середине 90-х японским разработчиком Юкихиро Мацумото.

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

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

Вместо заключения

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

Читайте также: