загрузка...

А не все ли равно


Оказывает ли следование закону Деметера (каким бы хорошим он не был с точки зрения теории) реальную помощь в создании программ, более простых в сопровождении?
Исследования [ВВМ96] показали, что классы в языке С++ с большими совокупностями откликов менее ошибкоустойчивы, чем классы с небольшими совокупностями (совокупность откликов представляет собой число функций, непосредственно вызываемых методами конкретного класса).
Рис. 5.1. Закон Деметера для функций
Поскольку следование закону Деметера уменьшает размер совокупности отклика в вызывающем отклике, то классы, спроектированные данным образом, также будут менее склонны к наличию ошибок (см. [URL 56], где приводится более подробная информация о статьях и других источниках по проекту Деметера).
Использование закона Деметера сделает вашу программу более адаптируемой и устойчивой, но не бесплатно: будучи "генеральным подрядчиком", ваша программа должна непосредственно делегировать полномочия и управлять всеми существующими субподрядчиками, не привлекая к этому клиентов вашего модуля. На практике это означает, что вы будете создавать большое количество методов-оболочек, которые просто направляют запрос далее к делегату. Эти методы-оболочки влекут за собой расходы во время исполнения и накладные расходы дискового пространства, которые могут оказаться весьма значительными, а для некоторых приложений даже запредельными.
Как и при использовании любой методики, вы должны взвесить все «за» и «против» для конкретного приложения. В проекте схемы базы данных обычной практикой является «денормализация» схемы для улучшения производительности: нарушение правил нормализации в обмен на скорость выполнения. Подобного же компромисса можно достичь и в этом случае. На самом деле, обращая закон Деметера и плотно связывая несколько модулей, вы можете получить существенный выигрыш в производительности. Ваша конструкция работает прекрасно, пока она известна и приемлема для этих связываемых модулей.
Физическая несвязанность
В данном разделе мы много говорим о сохранении логической несвязанности между элементами проектируемой системы. Однако существует взаимозависимость другого рода, которая становится весьма существенной с увеличением масштаба систем. В своей книге "Large-Scale С++ Software Design" [Lak96] Джон Лакос обращается к вопросам, касающимся отношений между файлами, каталогами и библиотеками, составляющими систему. Игнорирование этих проблем физического проектирования в крупномасштабных проектах приводит, помимо прочих проблем, к тому, что цикл сборки может растягиваться на несколько дней, а процедуры модульного тестирования могут сорвать сроки готовности всей системы. Г-н Лакос приводит убедительные доказательства того, что логическое и физическое проектирование должно осуществляться в тандеме и что устранение повреждений в большом фрагменте программы, нанесенных ему циклическими зависимостями, представляется чрезвычайно трудным делом. Мы рекомендуем вам прочесть эту книгу, если вы участвуете в разработке крупномасштабных проектов, даже если вы осуществляете реализацию на языке, отличном от С++.
В противном случае вы можете оказаться на пути к хрупкому, негибкому будущему.
Или вообще оказаться без будущего.
Другие разделы, относящиеся к данной теме:
• Ортогональность
• Обратимость
• Проектирование по контракту
• Балансировка ресурсов
• Всего лишь визуальное представление
• Команды прагматиков
• Безжалостное тестирование
Вопросы для обсуждения
• Мы обсудили, как делегирование полномочий облегчает соблюдение закона Деметера и, следовательно, уменьшает связывание. Однако написание всех методов, необходимых для пересылки вызовов к делегированным классам, является утомительной процедурой, чреватой ошибками. Каковы преимущества и недостатки написания препроцессора, который автоматически генерирует эти вызовы? Должен ли этот препроцессор запускаться только единожды, или же он должен применяться как составная часть процесса сборки?
Упражнения
24. Мы обсудили концепцию физической несвязанности в последней врезке. Какой из указанных ниже файлов заголовка в языке С++ характеризуется более сильным связыванием с остальной системой? (Ответ см. в Приложении В.)
person1.h
#include
"date.b"
class Person 1 {
private:
Date myBirthdate;
public:
Person1(Date &birthDate);
//...
person2.h
class Date;
class Person2 {
private:
Date *myBirthdate;
public:
25. В данном примере и примерах из упражнений 26 и 27 определите, являются ли показанные вызовы метода допустимыми с точки зрения закона Деметера. Первый пример написан на языке Java. (Ответом, в Приложении В.)
public void showBalance(BankAccount acct) {
Money amt = acct.getBalance();
printToScreen(amt.printFormat());
}
26. Этот пример также написан на языке Java. (Ответ см. в Приложении В.)
public class Colada {
private Blender myBlender;
private Vector myStuff;
public Colada() {
myBlender = new Blender();
myStuff = new Vector));
}
private void doSomething() {
myBlender.addlngredients(myStuff.elements());
}
}
27. Этот пример написан на языке С + +. (Ответ см. в Приложении В.)
void processTransaction(BankAccount acct, int) {
Person *who;
Money amt;
amt.setValue(123.45);
acct.setBalance(amt);
who = acct.getOwnerQ;
markWorkflow(who->name(), SET BALANCE);
}
27
Метапрограммирование
Никакая гениальность не спасает от любви к подробностям.
Восьмой закон Леви
Подробности смешивают все в нашей первоначальной программе – особенно если эти подробности часто меняются. Каждый раз, когда нам приходится входить в программу и вносить в нее изменения для того, чтобы привести ее в соответствие с изменившейся бизнес-логикой, законодательством или вкусами руководства, мы рискуем нарушить систему, т. е. внести в нее новый дефект.
Поэтому мы говорим: "Долой подробности!". Уберите их из программы. В этом случае мы можем сделать нашу программу гибкой при настройке и легко адаптирующейся к изменениям.
<< | >>
Источник: Эндрю Хант. Программист-прагматик. Путь от подмастерья к мастеру. 2004

Еще по теме А не все ли равно:

  1. Ситуация №3 Все произошло в людном месте, кто-либо из окружающих все видел и гопник не убежал, а лежит и жалобно стонет или скончался
  2. 65. ВОЗБУЖДЕНИЕ НЕНАВИСТИ ЛИБО ВРАЖДЫ, А РАВНО УНИЖЕНИЕ ЧЕЛОВЕЧЕСКОГО ДОСТОИНСТВА
  3. § 2.4. Убийство лица, заведомо для виновногонаходящегося в беспомощном состоянии, а равно сопряженное с похищением человека либо захватом заложника (п. «в» ч. 2 ст. 105 УК
  4. § 2.9. Убийство из корыстных побуждений или по найму, а равно сопряженное с разбоем, вымогательством или бандитизмом (п. «з» ч. 2 ст. 105 УК
  5. § 2.11. Убийство с целью скрыть другое преступление или облегчить его совершение, а равно сопряженное с изнасилованием или насильственными действиями сексуального характера (п. «к» ч. 2 ст. 105 УК)
  6. § 4.3. Получение взятки лицом, занимающим государственную должность Российской Федерации или государственную должность субъекта Российской Федерации, а равно главой органа местного самйуправления (ч. 3 ст. 290 УК
  7. ВСЕ ОБ ИМУЩЕСТВЕ.
  8. ВСЕ О ДОРОГАХ
  9. ВСЕ О ЗАКОНЕ
  10. ВСЕ О ЗАГРЯЗНЕНИИ
  11. Ликвидировать все секреты
  12. Не все обиды обоснованы
  13. Почему покупают не все
  14. УСТРАНИТЕ ВСЕ ПОТЕРИ
  15. § 1. Судьи все же зависимы