Интерес к многократному использованию программных компонент общего назначения в разных проектах возрастает. Для осуществления подобного, связи между различными частями системы должны быть минимальны и прозрачны.
Как мы уже отмечали в предыдущей главе, эти идеи были сформулированы специалистом по информатике Дэвидом Парнасом в виде правил, часто называемых принципами Парнаса:
∙Разработчик программы должен предоставить пользователю всю информацию, которая нужна для эффективного использования приложения, и ничего кроме этого.
∙Разработчик программного обеспечения должен знать только требуемое поведение компоненты и ничего кроме этого.
Следствие принципа отделения интерфейса от реализации состоит в том, что программист может экспериментировать с различными алгоритмами, не затрагивая остальные компоненты программы.
2.8. Формализация интерфейса
Продолжим разработку программы IIKH. На следующих нескольких этапах уточняется описание компонент. Сначала формализуются способы взаимодействия.
Следует определить, как будет реализована каждая из компонент. Компонента, характеризуемая только поведением(не имеющая внутреннего состояния), может быть
оформлена в виде функции. Например, компоненту, заменяющую все заглавные буквы в текстовой строке на строчные, разумнее всего сделать именно так. Компоненты с многими функциями лучше реализовать в виде классов. Каждой обязанности, перечисленной наCRC-карточкекомпоненты, присваивается имя. Эти имена станут затем названиями функций или процедур. Вместе с именами определяются типы аргументов, передаваемых функциям. Затем описывается(вся) информация, содержащаяся внутри компоненты. Если компоненте требуются некие данные для выполнения конкретного задания, их источник(аргумент функции, глобальная или внутренняя переменная) должен быть явно описан.
2.8.1. Выбор имен
Имена, связанные с различными действиями, должны тщательно подбираться. Шекспир сказал, что переименование не меняет сути объекта1 , но определенно не все имена будут вызывать в воображении слушателя одинаковые мысленные образы.
Как давно известно правительственным чиновникам, неясные и используемые в переносном смысле имена придают отпугивающий вид даже простейшим действиям. Выбор удобных имен необычайно важен. Они должны быть внутренне совместимы, значимы, коротки, содержательны. Часто значительное время тратится на нахождение правильного набора имен для выполняемых заданий и объектов. Являясь далеко не бесплодным и не бесполезным процессом, надлежащий выбор имен на ранней стадии проектирования значительно упрощает и облегчает дальнейшую разработку.
Были предложены следующие положения общего характера, регулирующие этот процесс
[Keller 1990]:
∙Используйте имена, которые можно произнести вслух. Основное правило: если вы не можете громко прочитать имя, забудьте о нем.
∙Применяйте заглавные буквы или символы подчеркивания для того, чтобы отметить начало нового слова в составном имени: CardReader илиCard_reader вместо нечитаемогоcardreader.
∙Тщательно проверяйте сокращения. Сокращение, ясное для одного человека, может быть загадочным для другого. Обозначает ли имяTermProcess последний процесс в цепочке(terminal process), или нечто, что прекращает выполнение процесса(terminate process), или же процесс, связанный с терминалом компьютера?
∙Избегайте многозначности имен. Имяempty для функции— обозначает ли оно проверку того, что некоторый объект пуст, или же она удаляет все значения из объекта(делает его пустым)?
∙Не используйте цифры в именах. Их легко спутать с буквами(0 какO, 1 какl, 2 как
Z, 5 как S).
∙Присваивайте функциям, которые возвращают логические(булевские) значения, такие имена, чтобы было ясно, как интерпретироватьtrue иfalse. Например, PrinterIsReady ясно показывает, что значениеtrue соответствует принтеру в рабочем состоянии, в то время какPrinterStatus является гораздо менее точным.
∙Дайте дорогостоящим (с точки зрения компьютерных ресурсов) и редко используемым операциям уникальные, четко выделяемые имена. При таком подходе уменьшается вероятность использования «не тех» функций.
Как только для всех действий выбраны имена, CRC-карточкадля каждой
компоненты переписывается заново с указанием имен функций и списка формальных аргументов. ПримерCRC-карточкидля компонентыDate приведен на рис. 2.5. Что осталось не установленным, так это то, как именно каждая компонента будет выполнять указанные действия.
1 «Что значит имя? Роза пахнет розой, хоть розой назови ее, хоть нет. Ромео под любым названьем был бы тем верхом совершенств, какой он есть». — Вильям Шекспир, «Ромео и Джульетта», действиеII, сцена2 (пер. Бориса Пастернака).
Необходимо еще раз «прокрутить» сценарий более детально, чтобы гарантировать, что все
действия учтены и вся необходимая информация имеется и доступна для соответствующих компонент.
Рис. 2.5. Обновленная CRC-карточкадля компонентыDate
2.9. Выбор представления данных