Часть

Процесс проектирования

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

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

1. Сущность программирования: без сюрпризов, минимум сцепления и максимум согласованности

Многие (если не все) правила в этой книге могут быть объединены в три метаправила (при желании), выраженные в заголовке этого раздела.

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

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

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

Согласованность является противоположностью сцепления; сущности, которые группируются вместе (пункты диалогового и простого меню, функции в модуле, или члены класса), должны быть связаны по назначению. Отсутствие связности также является "сюрпризом". У текстового редактора, которым я пользуюсь, имеется в меню пункт " Настройка" и, кроме того, дополнительные опции настройки рассыпаны по четырем другим всплывающим меню. Я ожидал согласованной конфигурации и, когда не смог найти нужную мне опцию в пункте " Настройка", то решил, что этой опции просто нет. Эта плохо спроектированная система до сих пор доставляет беспокойство; после года пользования я по-прежнему не помню, где расположена каждая опция, и

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

2. Подавляйте демонов сложности (часть 1)

Ричард Рашид (разработчик Mach - варианта ОС UNIX) выступил несколько лет назад с основным докладом на конференции разработчиков Microsoft. Его главный смысл состоял в том, что слишком большая сложность как в пользовательском интерфейсе, так и в программе является единственной большой проблемой, стоящей перед проектировщиками и пользователями программного обеспечения. По иронии, его речь была произнесена спустя два дня после провалившейся попытки показать нескольким тысячам очень толковых программистов, как программировать разработанный Microsoft интерфейс OLE 2.0 - один из самых сложных интерфейсов прикладного программирования, когда-либо мной виденных. (OLE означает "связь и внедрение объекта". Стандарт OLE 2.0 определяет интерфейс, который может использоваться двумя программами для взаимодействия между собой определенным образом. Это действительно объектная ориентация на уровне операционной системы).

Предыдущий оратор, который убеждал нас пользоваться библиотекой Microsoft Foundation Classes (MFC), сказал нам, что поддержка OLE в MFC "включает 20000 строк кода, необходимых для каждого базового приложения OLE 2.0". Аудитория была ошеломлена не полезностью MFC, а тем фактом, что для написания базового приложения OLE 2.0 требуется 20000 строк кода. Любой интерфейс такой сложности таит в себе изъян. Следующие несколько правил используют OLE для показа характерных проблем, но не думайте, что проблема запутанности характерна лишь для Microsoft - она свойственна всей отрасли.

2.1. Не решайте проблем, которых не существует

2.2. Решайте конкретную проблему, а не общий случай

Поучительно использовать OLE 2.0 как пример того, что случается со многими слишком сложными проектами. Имеется две главные причины сложности интерфейса OLE. Во-первых, он безуспешно пытается быть независимым от языка программирования. Идея таблицы виртуальных функций Си++ является центральной для OLE 2.0. Спецификация OLE