Лекция 7. Объектно-ориентированное программирование

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

Прежде всего, необходимость в целостном решении полной задачи

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

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

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

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

 

 

Сборка программы из автономно развивающихся компонентов опирается на формулировку достигаемой ими цели, понимание которой гарантирует не только корректность полученного результата, но и рациональность его ис- пользования. Формулировать цели частей программы – процесс нетривиаль- ный. В его основе лежат различные подходы к классификации понятий. Для демонстрации преимуществ ООП следует рассматривать задачи, решение ко- торых требует более одного шага. Первый шаг – программирование ядра про- граммы или его комплектация из готовых модулей с оформлением иерархии классов объектов, содержащих первичный комплект методов. Второй и по- следующие шаги – развитие иерархии классов и/или перегрузка методов. За- дачи, постановки которых допускают более одного сценария развития, по- требуют еще одного специального шага: определение абстрактных/виртуаль- ных классов в качестве точек варьирования возможного развития постановки задачи.

 

Общее представление

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

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

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

 

 

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

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

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

Фактически субъектом является суперкласс, объединяющий классы объ- ектов, обрабатываемые одноименными методами, т. е. функциями одного се- мейства. Так, при организации сложения можно считать, что существует су- перкласс «слагаемые», которое умеют складываться с другими слагаемыми. При этом они используют семейство функций – методов, реализующих сло- жение. В зависимости от полноты семейства результат может быть получен или не получен. Семейство легко пополняется добавлением одноименных функций с новыми комбинациями типов параметров.

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

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

 

 

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

«отдельная работа программируется отдельно, а выполняется взаимосвязано с другими работами», что требует совмещения декомпозиции программ с ме- тодами сборки – комплексации или интеграции программ из компонентов. Рассматривая комплексацию как еще одну «отдельную» работу, описывае- мую, например, в терминах управления процессами, можно констатировать, что эта работа больше определяет требования к уровню квалификации про- граммиста, чем объем программирования. При достаточно объективной ти- пизации данных и процессов, возникающих при декомпозиции и сборке про- грамм определенного класса, строят библиотеки типовых компонентов и раз- рабатывают компонентные технологии разработки программных продуктов – Corba, COM/DCOM, UML и т. п. Одна из проблем применения таких компонентов – их обширность.

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

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

ООП структурирует множество частных методов, используемых в про- грамме, в соответствии с иерархией классов объектов, обрабатываемых

 

 

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

 

Абстрактная машина

АС включает в себя аналоги ИП, ФП и ЛП с добавлением выбора метода в зависимости от класса объектов и разметки прав доступа.

АМ для языков ООП можно базировать на АМ для процедурно-импера- тивных языков стандартного прикладного программирования, по структуре она похожа на объединение машин для ФП и ИП:

AMO = < RO, SCO>, где SCO= <S, E, C, D, M>, где

AMO – абстрактная машина для ООП; RO – система команд для ООП;

S – стек операндов и результатов вычислений;

E – значения локальных переменных при вызовах функций; C – текущий стек программы;

D – дамп, обеспечивающий восстановление контекста программы при вы- ходе из метода;

M – общая память, хранящая константы, методы и объекты с их сигнату- рами.

Обозначения:

<[cm], ts> – код метода, таблица символов

<tsi (@cm, v), ret (#data)> – таблица метода,

v – символьные переменные, сигнатура возврата.

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

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

Значения реализованы как структура данных с тегами, задающими тип элемента данных.

Классы, поля и методы не являются значениями.

Ниже представлено дополнение абстрактной машины ИП для ООП.

 

 

Таблица 34

Типичные дополнительные команды виртуальной машины для языка ООП

Команда	Пояснение
NOP	Ничего не делает
RETURN	Возврат из функции
PUT	Установка поля в объекте
GET	Доступ к полю в объекте
INVOKE	Вызов метода
CHECK	Проверка соответствия типа объекта

Формат команд АМ имеет вид:

s e c d m→ s' e' c' d' m' – переход от старого состояния к новому.

Таблица 35