Если это необычно, зафиксируй это
Совет по кастингу типов C++, процитированный выше, иллюстрирует проблему, общую для советов отрицательного типа: подобные рекомендации своим существованием обязаны ограничениям соответствующего инструментария или языка. Для совершенного инструментария никогда не приходится давать отрицательные советы; каждое свойство такого инструментария сопровождается точным определением, когда оно применимо, а когда нет - критерий абсолютного вида. Поскольку совершенства в мире нет, то в хорошем инструментарии число отрицательных советов должно оставаться относительно небольшим. Если при изучении нового средства приходится часто сталкиваться с комментариями в форме "Пытайтесь избегать этого механизма, если только в нем нет обязательной необходимости", то это в большей степени говорит о проблеме с изучаемым инструментарием, а не о том, чтобы чему-нибудь вас обучить.
В таких ситуациях вместо того, чтобы давать подобные советы, лучше улучшить само средство или построить лучшее.
Типичные фразы, свидетельствующие о подобной ситуации:
...разве только вы знаете, что делаете. ...разве только вы абсолютно должны. Избегайте... если можете. Не пытайтесь... Обычно это предпочтительно, но... Лучше этого избегать...Литература по C/C++/Java имеет особую любовь к таким формулировкам. Типичным является совет "Не пишите в поля данных ваших структур, если только вы не должны" от того же эксперта по C++, предупреждавшего в одной из предыдущих лекций о нежелательности использования ОО-механизмов.
Этот совет загадочен. По каким причинам разработчики не должны записывать данные? Нарастающая Проблема Программистов, Пишущих в Поля Структуры Данных, Не Заботящихся Об Индустрии ПО США. Почему они делают это? Говорит Джил Добраядуша, Старший Программист из Санта Барбары, Калифорния: "Мое сердце склонно к добрым делам. В пространстве свопинга чувствуется такое одиночество! Я считаю своим долгом записывать данные в поле каждого из моих объектов, по меньшей мере один раз в день, даже если приходится писать его собственное значение. Иногда я возвращаюсь во время уикенда, просто чтобы сделать это". Действия программистов, подобных Джилу, приводят к растущим озабоченностям поставщиков ПО, заявляющих о необходимости специальных мер, чтобы справиться с этими проблемами. |
p> Другая известная ситуация возникает при попытках с помощью методологических советов устранить пороки языка разработки, - перекладывая ответственность за чьи-то ошибки на пользователей языка. В одной из предыдущих лекций (Исключения) цитировался совет программистам Java ("однако программист может повредить объекты"), направленный против прямого присваивания полю a.x := y как нарушающий принципы скрытия информации. Это удивительный подход; если вы думаете, что конструкция плоха, то зачем включать ее в язык программирования, а затем писать книгу, предписывающую будущим пользователям языка избегать ее.
Закон Деметры, цитированный ранее, дает еще один пример. Он ограничивает тип x в вызове x.f (...), появляющемся в программе r класса C: типами аргументов r; типами атрибутов C; типами создания (типами u в create u) для инструкций создания, появляющихся в r. Такие правила, если они обоснованы, должны быть частью языка. Но сами авторы полагают, что это было бы чересчур жесткое требование. Это правило делает невозможным, например, написать вызов my_stack.item.some_routine, применяющий some_routine к элементу в вершине стека.
Исследуя возможные причины появления этого закона и его исключений, можно предположить, что авторы не рассматривали понятия селективного выбора, позволяющего предоставлять разные права доступа разным клиентам. С этим механизмом необходимость в законах, подобных закону Деметры, просто бы отпала.
Эти наблюдения приводят к последнему принципу:
|
Фиксируйте все, что приводит к поломкам: принцип методологии Если вы встретились с необходимостью многих отрицательных советов:
|
