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

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

Как видно из названия этой технологии, достигается это все за счет объектов.

Что собой представляет объект

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

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

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

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

В настоящей главе для работы с классами и объектами используется синтаксис языка UML (Unified Modeling Language - унифицированный язык моделирования). Этот язык был специально разработан для моделирования приложений, начиная от объектов, которые должны входит в их состав, и операций, которые они должны выполнять, и заканчивая предполагаемыми способами их использования. Здесь применяют-

ся и объясняются только базовые возможности языка UML. Более сложные аспекты не затрагиваются, потому что изучение UML является специализированной темой, которой посвящены целые книги.

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

На рис. 8.1 для примера показано UML-представление класса принтера по имени

Printer.

Имя класса отображается в самом верхнем разделе данного прямоугольника (о двух нижних разделах будет рассказываться позже). На рис. 8.2 показано UML-представление экземпляра данного класса Printer по имени myPrinter.

myPrinter: Printer

Рис. 8.1. UML-представление класса Printer

Рис. 8.2. UML-представление экземпляра класса Printer по имени myPrinter

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

Свойства и поля

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

Различные фрагменты содержащихся в объекте данных все вместе образуют состояние этого объекта. Например, предположим, что имеется класс объектов, представляющий чашку кофе и потому имеющий имя CupOfCoffee. При создании экземпляра этого класса (т.е. создании объекта этого класса), для него нужно обязательно обеспечить состояние, чтобы он нес какой-то смысл. Для этого можно использовать свойства и поля с целью предоставления использующему данный объект коду возможности определять сорт используемого кофе, то, содержится ли в кофе молоко и/или сахар, является ли кофе растворимым и т.д. Тогда каждый конкретный объект CupOf Cofee будет иметь определенное состояние, например: Чашка колумбийского кофе с молоком и двумя ложками сахара .

Как поля, так и свойства добавляются путем ввода, поэтому информация может в них сохраняться в виде значений string, int и т.д. Свойства, однако, отличаются от полей тем, что они не предоставляют непосредственного доступа к данным. Объекты могут ограждать пользователей от мельчайших деталей своих данных, которые не нуждаются в представлении один к одному существующих свойств. Скажем, в случае поля для сохранения информации о количестве ложек сахара в экземпляре CupOfCof fee пользователи смогут помещать в него любые желаемые значения и подвергаться лишь тем ограничениям, которые имеются у использованного для хранения этой информации типа. То есть, например, в случае использования для хранения этих данных типа int пользователи смогут помещать в это поле любое значение в диапазоне от -2 147 483 648 до 2 147 483 647, как было показано в главе 3. Очевидно, что не все значения в этом диапазоне будут иметь смысл, особенно отрицательные, да

CupOfCoffee

-1-ВеапТуре : string -i-lnstant: bool -i-Milk : bool -i-Sugar: byte - -Description : string

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

такая информация является внутренней для класса. иМЬ-пЪед-

Никакая информация касательно доступа для чте-

стивлепии класса

ния и записи не предоставляется.

а Имя члена.

а Тип члена.

Для разделения имен членов и типов применяется двоеточие.

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

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

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

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

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

В UML-представлении класса имена свойств и полей отображаются во втором разделе, как показано на рис. 8.3.

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

а Доступность. Для общедоступных членов используется символ +, а для приватных - символ -. В целом, однако, приватные члены на приводимых в настоя-