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

Впрограммировании, основанном на абстракции данных, информация сознательно прячется в небольшой части программы. В частности, каждый объект из набора абстрактных типов данных, разрабатываемого программистом, имеет два»лица». Это аналогично дихотомии принципов Парнаса, которые обсуждались в главе2. С внешней точки зрения(клиента или пользователя) абстрактный тип данных представляет собой всего лишь совокупность операций, которые определяют поведение абстракций. С

 

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

Например, для абстрактного типа данныхstack пользователь видит только описание допустимых операций— скажем, push, pop, top. С другой стороны, программисту, реализующемуstack, необходимо манипулировать с конкретными структурами данных(рис. 3.1). Конкретные детали инкапсулированы в более абстрактный объект.

Рис. 3.1. Интерфейс и реализация для типа stack

Мы использовали термин экземпляр для обозначения представителя класса.

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

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

3.2. Разновидности классов

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

∙управление данными;

∙источники данных или посредники в передаче данных;

∙классы для просмотра данных;

∙вспомогательные, или упрощающие проектирование, классы.

Этот список не является исчерпывающим, однако он вполне подходит для учебных целей.

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

Классы-администраторыданныхData Managers, часто получающие именаData илиState, — это классы, основной обязанностью которых является поддержка данных или информации о состояниичего-либо. Например, для абстрактной модели игры в карты основная задача классаCard состоит в том, чтобы хранить масть и ранг(достоинство) карты. Классы-администраторыданных обычно являются фундаментальными строительными блоками проекта, а их прототипами в спецификации проекта являются существительные.

 

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

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

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

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

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

3.3. Пример: игра в карты