Если это необычно, зафиксируй это

Абстракция и точность

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

Конечно, это в большей мере относится к правилам, чем к общим руководствам по проектированию. Когда ищешь советы по выявлению того, какими должны быть классы проекта, или по построению нужной иерархии наследования, то нельзя ожидать рецептов вида: шаг-1, шаг-2, шаг-3.

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

Совет по кастингу типов C++, процитированный выше, иллюстрирует проблему, общую для советов отрицательного типа: подобные рекомендации своим существованием обязаны ограничениям соответствующего инструментария или языка. Для совершенного инструментария никогда не приходится давать отрицательные советы; каждое свойство такого инструментария сопровождается точным определением, когда оно применимо, а когда нет - критерий абсолютного вида. Поскольку совершенства в мире нет, то в хорошем инструментарии число отрицательных советов должно оставаться относительно небольшим. Если при изучении нового средства приходится часто сталкиваться с комментариями в форме "Пытайтесь избегать этого механизма, если только в нем нет обязательной необходимости", то это в большей степени говорит о проблеме с изучаемым инструментарием, а не о том, чтобы чему-нибудь вас обучить.

В таких ситуациях вместо того, чтобы давать подобные советы, лучше улучшить само средство или построить лучшее.

Типичные фразы, свидетельствующие о подобной ситуации:

...разве только вы знаете, что делаете.

...разве только вы абсолютно должны.

Избегайте... если можете.

Не пытайтесь...

Обычно это предпочтительно, но...

Лучше этого избегать...

Литература по C/C++/Java имеет особую любовь к таким формулировкам. Типичным является совет "Не пишите в поля данных ваших структур, если только вы не должны" от того же эксперта по C++, предупреждавшего в одной из предыдущих лекций о нежелательности использования ОО-механизмов.

Этот совет загадочен. По каким причинам разработчики не должны записывать данные? Нарастающая Проблема Программистов, Пишущих в Поля Структуры Данных, Не Заботящихся Об Индустрии ПО США. Почему они делают это? Говорит Джил Добраядуша, Старший Программист из Санта Барбары, Калифорния: "Мое сердце склонно к добрым делам. В пространстве свопинга чувствуется такое одиночество! Я считаю своим долгом записывать данные в поле каждого из моих объектов, по меньшей мере один раз в день, даже если приходится писать его собственное значение. Иногда я возвращаюсь во время уикенда, просто чтобы сделать это". Действия программистов, подобных Джилу, приводят к растущим озабоченностям поставщиков ПО, заявляющих о необходимости специальных мер, чтобы справиться с этими проблемами.

Другая известная ситуация возникает при попытках с помощью методологических советов устранить пороки языка разработки, - перекладывая ответственность за чьи-то ошибки на пользователей языка. В одной из предыдущих лекций (Исключения) цитировался совет программистам Java (" однако программист может повредить объекты "), направленный против прямого присваивания полю a.x := y как нарушающий принципы скрытия информации. Это удивительный подход; если вы думаете, что конструкция плоха, то зачем включать ее в язык программирования, а затем писать книгу, предписывающую будущимпользователям языка избегать ее.

Закон Деметры, цитированный ранее, дает еще один пример. Он ограничивает тип x в вызове x.f (...), появляющемся в программе r класса C: типами аргументов r ; типами атрибутов C ; типами создания (типами u в create u ) для инструкций создания, появляющихся в r. Такие правила, если они обоснованы, должны быть частью языка. Но сами авторы полагают, что это было бы чересчур жесткое требование. Это правило делает невозможным, например, написать вызовmy_stack.item.some_routine, применяющий some_routine к элементу в вершине стека.

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

Эти наблюдения приводят к последнему принципу:

Фиксируйте все, что приводит к поломкам: принцип методологии Если вы встретились с необходимостью многих отрицательных советов: · L Исследуйте поддерживающий инструментарий или язык, чтобы определить, не связано ли это с дефектами используемых средств. · L Если так, рассмотрите возможность изменений. · L Рассмотрите также возможность исключить проблему, переключившись на лучшее средство.

 

Тема 2. Образец проектирования: многопанельные интерактивные системы