6. Формулировка характеристик ООП
Фундаментальные характеристики ООП (в формулировке Алана Кея, одного из основоположников ООП и разработчика языка Смоллток):
Все является объектом.
Вычисления осуществляются путем взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение – это запрос на выполнение действия, дополненный набором параметров, которые могут понадобиться для выполнения действия.
Каждый объект имеет независимую память, которая состоит из других объектов.
Каждый объект является представителем класса, который выражает общие свойства объектов (например, таких, как целые числа или списки).
В классе задается поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.
Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определенного класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.
Традиционная модель, описывающая выполнение программы на компьютере, базируется на дуализме процесс–состояние. С этой точки зрения компьютер является администратором данных, следующим некоторому набору инструкций. Он перемещается по пространству памяти, изымает значения из ее ячеек (адресов памяти), некоторым образом преобразует полученные величины, а затем помещает их в другие ячейки. Проверяя значения, находящиеся в различных ячейках, мы определяем состояние машины или же результат вычислений. Хотя эта модель может рассматриваться как более или менее точный образ хранения предметов в почтовых ящиках или значений в ячейках памяти, но мало что из житейского опыта может подсказать, как структурировать задачу.
Антропоморфные описания являются отражением огромной выразительной силы метафор. Декомпозиция задачи на набор взаимодействующих объектов позволяет в ряде случаев применять естественные аналогии с повседневным опытом и способами моделирования, принятыми в конкретных предметных областях, для которых разрабатывается программное обеспечение
7. Развитие средств абстрагирования в программировании
Важность ООП-подхода можно понять, рассмотрев разнообразные механизмы, которые использовались программистами для контроля над сложностью. Сложность программного обеспечения в крупных проектах проявляется в том, что начиная с некоторого момента добавление новых разработчиков удлиняет, а не сокращает расписание работ над проектом.
Сложность порождается не только большим объемом задач, а вследствие уникального свойства программных систем, разработанных с использованием традиционных подходов – в этих системах существует большое количество перекрестных ссылок между компонентами. Перекрестные ссылки в данном случае обозначают зависимость одного фрагмента кода от другого. Действительно, каждый фрагмент программной системы должен выполнять некоторую работу, иначе он оказывается не нужен. Если эта деятельность нужна другим частям программы, то этот фрагмент должен обмениваться с ними данными. По этой причине, чтобы понять код фрагмента, надо знать и тот код, который им пользуется. Получается, что даже относительно независимый фрагмент программы нельзя полностью понять в изоляции от других фрагментов.
Главный способ борьбы со сложностью ПО – абстрагирование, те. способность отделить логический смысл фрагмента программы от проблемы его реализации. В некотором смысле ОО–подход не является революционным и может рассматриваться как естественный результат эволюции от процедур к модулям, далее к абстрактным типам данных и, наконец, к объектам.
7.1 Подпрограммы
Подпрограммы (процедуры и функции являются разновидностями подпрограмм) – это первые механизмы абстрагирования в языках программирования. Они позволяют сконцентрировать в одном месте работу, выполняемую многократно и затем многократно использовать этот код, вместо того чтобы писать его снова и снова. Они впервые обеспечили возможность скрытия информации – пользователи процедур могли не знать деталей реализованного алгоритма, а только интерфейс программы.
Недостатки подпрограмм: нет эффективного механизма скрытия данных, проблема использования одинаковых имен полностью не снимается.
В качестве примера применения подпрограмм можно привести стек, реализованный с помощью глобальных переменных.
int datastack[100];
int datatop = 0;
void init()
{
datatop = 0;
}
void push( int val )
{
if ( datatop < 100 )
datastack[datatop++] = val;
}
int top()
{
if ( datatop > 0 )
return datastack[datatop — 1];
return 0;
}
int pop()
{
if ( datatop > 0 )
return datastack[--datatop];
return 0;
}
7.2 Модули
Модули – улучшенный метод создания и управления совокупностями имен и связанными с ними значениями. Пример со стеком: есть информация (интерфейсные процедуры), которая должна быть широко доступной, и есть некоторые данные (собственно данные стека), доступ к которым должен быть ограничен. Суть модуля состоит в разбиении пространства имен на две части: открытая (public) часть является доступной извне модуля, закрытая (private) часть доступна только внутри модуля. Типы, данные (переменные) и процедуры могут быть отнесены к любой из двух частей.
Были сформулированы (Д. Парнас, 1972) два принципа использования модулей:
Пользователя модуля надо снабдить минимально необходимой для его использования информацией.
Разработчика надо снабдить минимально необходимой информацией для создания модуля.
Достоинства модулей: эффективный механизм скрытия данных.
Недостатки: нет способа размножения экземпляров областей данных. Для преодоления этого недостатка была разработана следующая концепция.
7.3 Абстрактные типы данных
АТД создаются программистом, но с этими типами можно работать так же, как и со встроенными типами данных. Каждому АТД соответствует набор допустимых значений (м.б. бесконечный) и ряд элементарных операций, которые могут быть выполнены над данными. Например, стек можно определить как АТД и служебные функции – как единственные действия, которые можно производить над отдельными экземплярами стеков.
Модули часто используются для реализации АТД, но непосредственной логической связи между этими идеями нет, хотя они и близки. Чтобы построить АТД, надо уметь:
Экспортировать определения типа данных.
Делать доступным набор операций, использующихся для манипулирования экземплярами типа данных.
Защищать данные, связанные с типом данных, чтобы с ними можно было работать только через указанные подпрограммы.
Создавать несколько экземпляров АТД.
В этом определении модули служат только как механизм скрытия информации для выполнения шагов 2) и 3). Остальные шаги могут быть выполнены с помощью соответствующей техники программирования.
7.4 Объекты. Сообщения, наследование и полиморфизм.
Правда, что объекты являются АТД, но понятия ООП, хотя и строятся на идеях АТД, добавляют к ним важные новшества по части разделения и совместного использования программного кода.
Главная идея: пересылка сообщений. Действие инициируется по запросу, обращенному к конкретному объекту, а не через вызов функции (хотя это м.б. только способ интерпретации, а не реализации). Неявная идея в пересылке сообщений – то, что интерпретация сообщения может меняться для различных объектов. Например, push для стека и робота-манипулятора означают разные действия. Имена операций не обязаны быть уникальными, что приводит к более читаемому и понятному исходному тексту.
Механизм наследования: позволяет различным типам данных совместно использовать один и тот же код, приводя к уменьшению его размера и повышению функциональности.
Полиморфизм: перекраивает этот общий код так, чтобы удовлетворить конкретным особенностям отдельных типов данных.
Упор на независимость индивидуальных компонент позволяет использовать процесс пошаговой сборки, когда отдельные блоки ПО разрабатываются, программируются и отлаживаются до того, как они объединяются в большую систему.
Структурный и ОО-подходы различаются тем, что в первом случае программист думает, как обрабатывать структуры данных, а во втором, что именно эти структуры данных "могут сделать".
|
