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

 

Damir Tenisheff
http://www.tenisheff.ru/

 

Разработка объектно-ориентированной парадигмы была вызвана трудностями, имевшими место в структурном программировании.

 

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

 

Множество ошибок появляется при внесении в текст программы изменений.

 

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

 

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

 

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

  • неполные
  • по большей части ошибочны
  • противоречивы
  • не описывают поставленную задачу подробно.

 

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

 

Причины:

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

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

Почему же?

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

 

Сложность вызывается четырьмя основными причинами:

·        сложностью реальной предметной области, из которой исходит заказ на разработку

·        трудностью управления процессом разработки

·        необходимостью обеспечить достаточную гибкость программы

·        неудовлетворительными способами описания поведения больших дискретных систем.

 

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

 

 

Структура сложных систем

 

Примеры: структура компьютера, структура растения, структура человека.

 

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

 

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

 

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

 

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

 

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

 

Пять признаков сложной системы

 

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

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

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

4.      Иерархические подсистемы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных.

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

 

 

Различие алгоритмической и объектно-ориентированной декомпозиции.

 

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

 

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

 

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

 

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

 

 

Основные элементы объектной модели

 

Объект

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

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

На концептуальном уровне объекты выступают как совокупность обязательств.

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

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

 

 

Класс

Класс – есть описание структуры объекта и его интерфейса. Представляет контракт между объектом и всеми его клиентами.

 

Абстрагирование

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

 

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

 

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

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

 

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

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

Класс, поведение и структура которого наследуется называется базовым (родительским) классом, а класс, который наследует – производным.

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

Наследование есть классификация. Классификация позволяет повторно использовать единожды осмысленные и реализованные свойства класса.

 

Полиморфизм

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

 

Литература:
Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание. Издательство "Бином", 1999 г.

А.Шаллоуей. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию. М. Издательский дом "Вильямс", 2002 г.