Освой самостоятельно С++ за 21 день.
Шрифт:
Классы интерфейса инкапсулируют протоколы интерфейса и таким образом защищают код программы от изменений в другой системе. Они позволяют менять ваш собственный проект или подстраиваться к изменениям структуры других систем, не нарушая остального кода. Пока две системы продолжают поддерживать согласованный интерфейс, они могут развиваться независимо друг от друга.
Обработка данных
Аналогично создаются классы обработки данных. Если надо сделать преобразование из одного формата в другой (например, из градусов Фаренгейта в градусы Цельсия или из английской системы
Отчеты
Каждый отчет, выводимый системой (или связанная группа отчетов) является кандидатом в классы. Протокол формирования отчета, куда входит сбор информации и способ ее отображения, следует инкапсулировать в класс обзора.
Устройства
Если система взаимодействует с устройствами или управляет ими (такими как принтеры, модемы, сканеры и т.п.), то особенности протокола устройства следует инкапсулировать в классе устройства. Благодаря этому, внося изменения в класс устройства, можно подключать к системе новые устройства, не нарушая остального кода.
Статическая модель
Когда создан первоначальный набор классов, пора начинать моделировать их отношения и взаимодействия. Для большей ясности сначала объясним статическую модель, а затем — динамическую. При реальном процессе проектирования можно свободно переходить от одной модели к другой, заполняя обе подробностями, фактически добавляя новые классы и описывая их по мере продвижения.
Статическая модель сосредоточена в трех областях: распределении ответственности, атрибутах и взаимодействии. Наиболее важная из них (на что в первую очередь обратим внимание) — это распределение ответственности между классами. Перед каждым классом должна быть поставлена одна конкретная задача, за выполнение котб- рой он несет ответственность.
Это не означает, что у каждого класса есть только один метод. Класс может содержать десятки методов. Однако все они должны быть согласованными и взаимосвязанными, т.е. должны обеспечивать выполнение единой задачи.
В хорошо спроектированной системе каждый объект является экземпляром класса, имеющего четко определенный набор функций и отвечающего за выполнение конкретной задачи. Классы обычно делегируют несвойственные им задачи другим, связанным с ними классам. Создание классов, имеющих одну область ответственности, — основа написания читабельного и легко поддерживаемого кода.
Чтобы разобраться с ответственностью классов, следует начать проектирование с создания карточек CRC.
Карточки CRC
CRC означает Class (класс), Responsibility (ответственность), Collaboration (сотрудничество). CRC представляет собой обычную бумажную карточку размером, не превышающим используемые в картотеках. Работая с такими карточками, вы, как Чапаев с помощью картошки, сможете наглядно объяснить коллегам, которым будет поручена разработка отдельных классов, как вы мыслите наладить распределение ответственности за выполнение тактических и стратегических задач между классами проекта.
Как проводить заседания с карточками
На каждое заседание с карточками следует приглашать от трех до шести человек. Если людей больше, то теряется управляемость. Кроме того, во время дискуссии гораздо проще прийти к консенсусу, если в заседании участвует не слишком много людей. Кратко остановимся на том, кто в идеале должен участвовать в разработке серьезного проекта (если вы не хотите свалить на себя всю ответственность за провал). Итак, вы главный исполнитель. Пригласите как минимум одного ведущего специалиста по программной архитектуре, имеющего опыт в анализе и проектировании объектно-ориентированных программ. Не мешает также включить в состав минимум одного или двух "экспертов по домену", не понаслышке знающих проблему, которую вы хотите решить с помощью разрабатываемой программы.
В будущем вам потребуются менеджеры (если не адвокат), но не сейчас. Это творческое непринужденное заседание не для прессы и не для рекламы. Цель состоит в том, чтобы провести исследование, высказать рискованные предложения и в ходе дискуссии решить, какой класс нагрузить той или иной проблемой.
Заседание по CRC начинается с того, что группа рассаживается за столом, на котором лежит небольшая стопка карточек. В верхней части каждой из них пишется название одного из классов. Начертите сверху вниз линию, разделив карточку на две части, и слева напишите Ответственность, а справа — Сотрудничество.
Начинайте заполнять карточки по самым важным из определенных вами классов. С обратной стороны дайте небольшое описание в одно или два предложения. Можно также указать, уточнением (производным) какого класса является данный класс, если это очевидно к моменту работы с карточкой. Просто под именем класса напишите Надкласс: и впишите имя класса, от которого данный класс производится.
Сфокусируемся на распределении ответственности
Основным пунктом повестки дня заседания является определение ответственности каждого класса. Не обращайте много внимания на атрибуты, фиксируйте по мере продвижения только самые существенные и очевидные из них. Если для выполнения задачи класс должен делегировать часть работы другому классу, то эта информация указывается в столбце Сотрудничество.
В ходе работы обращайте внимание, сколько пунктов появилось на карточке класса в столбце Ответственность. Если на карточке не хватает места, то это повод задуматься, не следует ли разделить данный класс на два. Помните, каждый класс должен отвечать за выполнение одной задачи, поэтому все пункты в столбце Ответственность должны быть логически и функционально взаимосвязанными.
На данном этапе проектирования не стоит задумываться над тем, каким образом будет объявлен класс в программе и сколько открытых и закрытых методов он будет содержать. Обращайте внимание только на то, за что этот класс отвечает.
Как сделать класс живым
Главным свойством карточек CRC является то, что их можно сделать антропоморфными, т.е. каждый класс наделяется свойствами человека. Посмотрим, как это работает. После определения первоначального набора классов разложите по кругу на столе карточки CRC в произвольном порядке и вместе пройдитесь по сценарию. Например, вернемся к предложенному ранее сценарию.
Клиент выбирает операцию снятия наличных с расчетного счета. На счете в банке имеется достаточная сумма, в ATM достаточно наличных и заправлена лента для квитанций, а сеть включена и работает. Кассовый аппарат ATM просит указать сумму, которая не должна превышать $300. Машина выдает указанную сумму и печатает квитанцию для клиента.