Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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




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

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

Конечно, это в большей мере относится к правилам, чем к общим руководствам по проектированию. Когда ищешь советы по выявлению того, какими должны быть классы проекта, или по построению нужной иерархии наследования, то нельзя ожидать рецептов вида: шаг-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. Образец проектирования: многопанельные интерактивные системы




Поделиться с друзьями:


Дата добавления: 2014-12-07; Просмотров: 330; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.01 сек.