Исключения

Многие правила имеют исключения. Но если вы представляете методологическое правило и желаете указать, что оно не всегда применимо, следует точно определить исключения. В противном случае правило будет неэффективным: каждый раз, когда разработчик действительно нуждается в совете, он будет судорожно размышлять применимо правило или нет.

В одной из статей по методологии ПО после представления довольно строгого множества правил приводится следующий абзац:

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

После чтения этого пассажа довольно трудно решить, насколько серьезно авторы предлагают свои собственные правила, - когда их следует применять и когда лучше ими не пользоваться?

Что ошибочного, если исключения не присутствуют в общих руководствах? Поскольку проектирование ПО является сложной задачей, то иногда необходимо (хотя всегда нежелательно) к абсолютно положительному правилу " Всегда делай X в ситуации A " или к абсолютно отрицательному " Никогда не делай Y в ситуации A " добавлять квалификацию " за исключением случаев B, C и D ". Такое квалифицированное правило остается абсолютно положительным или отрицательным: просто его область применения сужается, теперь это не все A, но A лишенное B, C и D. Расплывчатая формулировка исключений неприемлема (" в некоторых ситуациях потери могут быть больше преимуществ " - что это за ситуации?). Позже в цитируемой статье показан пример, нарушающий правило, но исключение проверяется в терминах, специально подобранных для данного случая, а оно должно быть частью правила:

Включение исключений: принцип методологии Если методологическое правило представляет общеприменимое руководство, предполагающее исключения, то исключения должны быть частью правила.

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

Этот принцип возвращает каждому правилу форму: "Делай это..." абсолютно положительного правила или "Не делай этого..." абсолютно отрицательного.

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

Дата добавления: 2014-12-07