Файл: История и развитие методологии объектно-ориентированного программирования. Сферы ее применения..pdf

Основами методологии объектно-ориентированного программирования являются инкапсуляция (объединение данных и методов, работающих с ними в классе), наследственность (способность одного вида классов заимствовать поля и методы других классов) и полиморфизм (способность действий, выполняемых одноименными методами различаться в зависимости от того, к какому из классов относится тот или иной метод). Помимо выше упомянутых принципов, методология объектно-ориентированное программирования состоит из: абстракции, класса, объекта, предметной области, объектно-ориентированного анализа и проектирования. Абстракция (abstraction) - характеристика сущности, которая отличает ее от других сущностей. Абстракция определяет границу представления соответствующего элемента модели и применяется для определения фундаментальных понятий ООП, таких как класс и объект. ^[25]

Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Абельсон и Суссман назвали такое разделение смысла и реализации барьером абстракции ^[26], который основывается на принципе минимизации связей, когда интерфейс объекта содержит только существенные аспекты поведения и ничего больше.^[27] Первым, кто указал на необходимость построения систем в виде структурированных абстракций, был Дейкстра. Позднее Парнас ввел идею скрытия информации^[28], а в 70-х годах ряд исследователей, главным образом Лисков и Жиль^[29], Гуттаг ^[30], и Шоу^[31], разработал механизмы абстрактных типов данных. Хоар дополнил эти подходы теорией типов и подклассов^[32]. Развивавшиеся достаточно независимо технологии построения баз данных также оказали влияние на объектный подход^[33], в первую очередь благодаря так называемой модели "сущность-отношение" (ER, entity-relationship) ^[34]. В моделях ER, впервые предложенных Ченом ^[35], моделирование происходит в терминах сущностей, их атрибутов и взаимоотношений. Разработчики способов представления данных в области искусственного интеллекта также внесли свой вклад в понимание объектно-ориентированных абстракций. В 1975 г. Мински выдвинул теорию фреймов для представления реальных объектов в системах распознавания образов и естественных языков^[36]. Фреймы стали использоваться в качестве архитектурной основы в различных интеллектуальных системах.

---

Класс — универсальный, комплексный тип данных, абстракция совокупности реальных объектов. Каждый объект строится из класса.^[37]

Объект — это тип данных, поэтому он определяется в разделе описания типов^[38]. В методологии объектно-ориентированного программирования рассматривается как экземпляр класса. Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств.^[39] Понятия класса и объекта настолько тесно связаны, что невозможно говорить об объекте безотносительно к его классу. Однако существует важное различие этих двух понятий. В то время как объект обозначает конкретную сущность, определенную во времени и в пространстве, класс определяет лишь абстракцию существенного в объекте. Таким образом, можно говорить о классе "Млекопитающие", который включает характеристики, общие для всех млекопитающих. Для указания на конкретного представителя млекопитающих необходимо сказать "это - млекопитающее" или "то - млекопитающее".

Иерархия классов представляет собой классификацию объектных типов, рассматривая объекты как реализацию классов.

Управлять большим количеством разрозненных классов довольно сложно. С этой проблемой можно справиться путем упорядочивания и ранжирования классов, то есть объединяя общие для нескольких классов свойства в одном классе и используя его в качестве базового. Эту возможность предоставляет механизм наследования.^[40]

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

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

---

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

Описанная выше текстовая информация о соотношении классов в данном примере обладает одним серьезным недостатком, а именно, отсутствием наглядности. В этой связи возникает вопрос: а возможно ли представить иерархию наследования классов в визуальной форме? В понятийной логике для изображения понятий используются окружности или прямоугольники. С помощью графической нотации на рисунке под номером 2, иерархию классов для рассмотренного примера можно представить в виде вложенных прямоугольников или окружностей, каждый из которых соответствует отдельному классу.^[41]

­­­Рис. 2.0, Пример иерархии классов.

3. Иерархия вложенности классов для примера общего класса

"Компьютер"

Источник: НОУ «Интуит». Лекция 1: Современные технологии объектно-ориентированного анализа и проектирования информационных систем. URL:[ http://www.intuit.ru/EDI/25_12_15_1/1450995683-14467/tutorial/92/objects/1/files/1-1.gif]

Инкапсуляция характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. На примере с классом "Компьютер" нетрудно проиллюстрировать инкапсуляцию следующим образом. Основным субъектом, который взаимодействует с объектами этого класса, является пользователь. Вполне очевидно, что не каждый пользователь в совершенстве знает внутреннее устройство того или иного компьютера. К тому же, отдельные детали этого устройства сознательно скрыты в корпусе системного блока или монитора. А в случае нарушения работы компьютера, которое является причиной неадекватности его поведения, необходимый ремонт выполняет профессиональный специалист.^[42]

---

Предметная область (domain) - часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения конкретной задачи. Выделение исходных или базовых компонентов предметной области, требуемых для решения той или иной задачи, представляет, в общем случае, нетривиальную проблему. Сложность данной проблемы проявляется в неформальном характере процедур или правил, которые можно применять для этой цели. Более того, эта работа должна выполняться совместно со специалистами или экспертами, хорошо знающими предметную область. Например, если разрабатывается база данных для обслуживания пассажиров крупного аэропорта, то в проектировании концептуальной схемы базы данных должны принимать участие штатные сотрудники аэропорта. Эти сотрудники хорошо знают весь процесс обслуживания пассажиров или данную предметную область. Сложность моделирования предметной области и разработки корпоративных информационных систем привело к появлению новой методологии объектно-ориентированный анализ и проектирование.^[43] Полиморфизм также один из основных принципов ООП. Под полиморфизмом (греч. Poly - много, morfos - форма) понимается свойство объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут различаться в зависимости от того, к какому из классов относится тот или иной метод.

Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов. Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования:^[44] здесь нужно по-другому представлять себе процесс декомпозиции, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования. Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектно-ориентированного проектирования лежит методология объектно-ориентированного программирования.

---

Компонентно-ориентированное программирование является логическим продолжением объектно-ориентированного программирования, по сути это - набор правил и ограничений, направленных на построение крупных развивающихся программных систем с большим временем жизни.^[45] Можно сказать, что КОП — это такое ООП, которое подчинено требованиям безопасности "старого" структурного и модульного программирования примерно в том виде, в каком эти требования были реализованы в классической Модуле-2 (в отличие от языков типа Smalltalk, в которых ООП является основным механизмом, который применяется без ограничений). КОП можно описать примерно такой формулой:

КОП = ООП

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

+ безопасность (статический контроль типов переменных и автоматическое управление памятью)

- наследование реализации через границы модулей. ^[46]Понятие программного компонента (software component) является одним из ключевых в современной инженерии ПО.

Этим термином обозначают несколько различных вещей, часто не уточняя подразумеваемого в каждом конкретном случае смысла. Если речь идет об архитектуре ПО (или ведет ее архитектор ПО), под компонентом имеется в виду то же, что часто называется программным модулем. Это достаточно произвольный и абстрактный элемент структуры системы, определенным образом выделенный среди окружения, решающий некоторые подзадачи в рамках общих задач системы и взаимодействующий с окружением через определенный интерфейс На диаграммах компонентов в языке UML часто изображаются компоненты, являющиеся единицами сборки и конфигурационного управления, — файлы с кодом на каком-то языке, бинарные файлы, какие-либо документы, входящие в состав системы. Иногда там же появляются компоненты, представляющие собой единицы развертывания системы, — это компоненты уже в третьем, следующем смысле. ^[47]

Компоненты развертывания являются блоками, из которых строится компонентное программное обеспечение. Эти же компоненты имеются в виду, когда говорят о компонентных технологиях, компонентной или компонентно-ориентированной (component based) разработке ПО, компонентах JavaBeans, EJB, CORBA, ActiveX, VBA, COM, DCOM, .Net, Web-службах (web services), а также о компонентном подходе, упоминаемом в названии данного курса. Такой компонент представляет собой структурную единицу программной системы, обладающую четко определенным интерфейсом, который полностью описывает ее зависимости от окружения. Такой компонент может быть независимо поставлен или не поставлен, добавлен в состав некоторой системы или удален из нее, в том числе, может включаться в состав систем других поставщиков.^[48] Различие между этими понятиями, хотя и достаточно тонкое, все же может привести к серьезному непониманию текста или собеседника в некоторых ситуациях.

---