Файл: Основные понятия объектно-ориентированного программирования (Анализ существующих объектно-ориентированных сред разработки программ).pdf

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

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

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

Достоинства ООП:

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

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

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

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

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

К недостаткам ООП также можно отнести следующее:

• 1. В сложных иерархиях классов поля и методы в большинстве случаев наследуются с различных уровней. Порой сложно определить методы и поля, которые относятся к данному классу. Чтобы получить такую информацию нужны специальные инструменты, называемые навигаторами классов.
  2. Злоупотребление инкапсуляцией приводит к сложностям расширения класса из-за скрытой логики и данных. Основным моментом является не то, что клиенту не разрешается знать о каких-либо данных, а то, что клиенту для работы с классом нет необходимости знать данные.
  3. Также инкапсуляция влияет на время выполнения программы.

Рисунок 2 – Преимущества и недостатки объектно-ориентированного подхода

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

Три краеугольных камня ООП — наследование, инкапсуляция и полиморфизм — мощные средства/концепции, но также со своими недостатками.

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

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

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

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

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

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

Много реальных приложений требуют решения проблем с множеством составных частей. Когда вы выбираете объектно-ориентированный подход для разработки программы, вы столкнётесь с разными головоломками вроде «как распределить функциональность приложения между разными объектами?» или «как управлять взаимодействием и обменом данными между разными объектами?».

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

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

Предположим, что мы хотим создать общий (полиморфный) объект, который принимает какие-то данные и флаг состояния в качестве параметров. Если состояние говорит, что данные валидные (т.е. status === true), на данных можно применить функцию, результат которой будет возвращён вместе с флагом состояния. В противном случае мы не применим функцию и просто вернём данные и флаг.

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

Глава 2. Анализ современных подходов к объектно-ориентированному программированию

2.1 Анализ существующих объектно-ориентированных сред разработки программ

Развитие объектно-ориентированного подхода в технологии программирования подтолкнуло развитие сред визуального программирования.

Примеры объектно-ориентированных языков:

• 1. Pascal. С выходом Delphi 7 на официальном уровне стал называться Delphi. Основная область использования Object Pascal - написание прикладного ПО.
  2. C++ широко используется для разработки программного обеспечения, является одним из самых популярных языков. Применяется для создания ОС, прикладных программ, драйверов устройств, приложений, серверов, игр.
  3. Java - транслируется в байт-код, обрабатывается виртуальной машиной Java. Преимуществом такого способа выполнения является независимость от операционной системой и оборудования. Существующие семейства: Standard Edition, Enterprise Edition, Micro Edition, Card.
  4. JavaScript применяется в качестве языка сценариев для web-страниц. Синтаксис во многом напоминает Си и Java. Является реализацией Ecmascript. Сам Ecmascript используется в качестве основы для построения других скриптовых языков, таких как JScript, ActionScript.
  5. Objective-C построен на основе языка Си, а сам код Си понятен компилятору Objective-C.
  6. Perl - высокоуровневый интерпретируемый динамический язык общего назначения. Имеет богатые возможности для работы с текстом, изначально разработан именно для манипуляций с текстом. Сейчас используется в системном администрировании, разработке, сетевом программировании, биоинформатике и т. д.
  7. PHP. Аббревиатура переводится как препроцессор гипертекста. Применяется для разработки веб-приложений, в частности серверной части. С его помощью можно создавать gui-приложения с помощью пакетов PHP-GTK, PHP-Qt, WinBinder.
  8. Python - язык общего назначения, ориентирован на повышение производительности разработчика и читаемость кода. Был разработан проект Cython, с помощью которого осуществляется трансляция программ, написанных на Python в код на языке Си.

Рисунок 3 – Наиболее распространенные среды разработки

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

2.2 Анализ существующих способов сравнения объектно-ориентированных сред разработки

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

• 1. Статическая типизация
  2. Динамическая типизация
  3. Явная типизация
  4. Неявная типизация
  5. Неявное приведение типов в неоднозначных ситуациях
  6. Шаблоны
  7. Неуправляемые указатели
  8. Ручное управление памятью
  9. Сборка мусора

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

Глава 3. Сравнительный анализ современных объектно-ориентированных языков программирования

3.1 Обоснование выбора различных сред

Проведем сравнительный анализ языков программирования: Delphi, Python, C++, C#, Java.

Краткая характеристика каждого языка программирования представлена в таблице 3.1.