1.2
Элементы объектной
модели
-
Элементы объектной модели.
-
Абстрагирование.
-
Инкапсуляция.
Под
объектно-ориентированным программированием
(object-oriented programming, OOP) следует понимать методологию реализации, при
которой программа организуется, как совокупность сотрудничающих
объектов, каждый из которых является экземпляром какого-либо
класса, а классы образуют иерархию наследования. При этом классы
обычно статичны, а объекты очень динамичны, что поощряется
динамическим связыванием и полиморфизмом (пока не обращайте
внимания на то, что большая часть слов этого определения Вам не
понятна). Несмотря на то,
под OOP следует понимать только то, что было
написано выше, под ним часто понимают объектно-ориентированный
подход к созданию ПО. Последний наравне
с OOP включает в себя объектно-ориентированный анализ
(object-oriented analisys, OOA) н объектно-ориентированное проектирование
(object-oriented design). Все это понятия тесно связанны с
понятиями объекта, класса и объектной
модели.
Элементы объектной
модели.
Объектно-ориентированный подход принципиально
отличаются от традиционных подходов структурного проектирования:
здесь нужно по-другому представлять себе процесс декомпозиции, а
архитектура получающегося программного продукта в значительной
степени выходит за рамки представлений, традиционных для
структурного программирования. Это связанно с тем, что программы,
созданные, при помощи традиционных подходов оперируют в основном
глаголами (функциями). Мы пытаемся запрограммировать задачу как
последовательность функций и алгоритмов, проведя, для этого, так
называемую алгоритмическую декомпозирую. При объектном подходе
проводится объектная декомпозиция, и программа представляется уже
как набор взаимодействующих друг с другом
объектов.
Объектно-ориентированная технология основывается
на так называемой объектной модели. Основными ее принципами
являются: абстрагирование, инкапсуляция, модульность,
иерархичность, типизация, параллелизм и сохраняемость. Каждый из
этих принципов сам по себе не нов, но в объектной модели они
впервые применены в совокупности. Первые четыре принципа являются
обязательными в том смысле, что без них модель не будет считаться
объектной. Последние три дополнительными. Рассмотрим подробно все
принципы.
Абстрагирование
Абстрагирование выделяет существенные
характеристики некоторого объекта, отличающие его от всех других
видов объектов и, таким образом, четко определяет его
концептуальные границы с точки зрения наблюдателя. Фраза “с точки
зрения наблюдателя” важна, так как разные люди могут иметь
совершенно разные взгляды на вещь или
проблему.
Абстрагирование концентрирует внимание на внешних
особенностях объекта и позволяет отделить самые существенные
особенности поведения от несущественных. Абельсон и Суссман назвали
такое разделение смысла и реализации барьером абстракции, который
основывается на принципе минимизации связей, когда интерфейс
объекта содержит только существенные аспекты поведения и ничего
больше. Существует еще один дополнительный принцип, называемый
принципом наименьшего удивления, согласно которому абстракция
должна охватывать все поведение объекта, но не больше и не меньше,
и не привносить сюрпризов или побочных эффектов, лежащих вне ее
сферы применимости.
Выбор правильного набора абстракций для заданной
предметной области представляет собой главную задачу
объектно-ориентированного проектирования. Существует 4 вида
абстракций (перечислены по мере уменьшения
полезности).
-
Абстракция сущности. Объект представляет собой
полезную модель некой сущности в предметной
области.
-
Абстракция поведения. Объект состоит из
обобщенного множества операций.
-
Абстракция виртуальной машины. Объект группирует
операции, которые либо вместе используются более высоким уровнем
управления, либо сами используют некоторый набор операций более
низкого уровня.
-
Произвольна абстракция. Объект включает в себя
набор операций, не имеющих друг с другом ничего
общего.
Инкапсуляция
Инкапсуляция – это процесс
отделения друг от друга элементов абстракции, определяющих ее
устройство и поведение; инкапсуляция служит для того, чтобы
изолировать контрактные обязательства абстракции от их
реализации.
Абстракция и инкапсуляция дополняют друг друга:
абстрагирование направлено на наблюдаемое поведение объекта, а
инкапсуляция занимается внутренним устройством. Чаще всего
инкапсуляция выполняется посредством скрытия информации, то есть
маскировкой всех внутренних деталей, не влияющих на внешнее
поведение объекта. Обычно скрываются и внутренняя структура объекта
и реализация его методов. Необходима инкапсуляция для того, что бы
та модель которую мы выражаем средствами языков моделирования и
программирования была адекватной.
Рассмотрим пример растения. У растения существует
такой атрибут как размер. Что может повлиять на размер? На
размер могут повлиять количество солнечного света, количество воды,
количество навоза наконец. Вы воздействуете на размер меняя
количество того или другого из перечисленных параметров. Если Вы
будете поливать цветок он будет расти. При этом, Вы не можете в
реальном мире одним усилием мысли заставить цветок вырасти на два
метра. Это нереально, так как только сам цветок представляет себе
механизмы по которым меняется его размер. И было бы
естественно, что бы и в программной модели цветка не было
возможности менять размер цветка явно. Поэтому, мы спрячем атрибут
– размер цветка в реализации, а в интерфейсе модели выставим в
метод «ВоздействоватьНаРост» с такими параметрами как количество
света, воды и навоза.
Скрытие информации - понятие относительное: то,
что спрятано на одном уровне абстракции, обнаруживается на другом
уровне. Забраться внутрь объектов можно; правда, обычно требуется,
чтобы разработчик класса-сервера об этом специально позаботился, а
разработчики классов-клиентов не поленились в этом разобраться.
Инкапсуляция не спасает от глупости; она, как отметил Страуструп,
"защищает от ошибок, но не от жульничества" Разумеется, язык
программирования тут вообще ни при чем; разве что операционная
система может ограничить доступ к файлам, в которых описаны
реализации классов. На практике же иногда просто необходимо
ознакомиться с реализацией класса, чтобы понять его назначение,
особенно, если нет внешней документации.