Словарик философствующего информатика/Несвязность и закон Деметры: различия между версиями

Содержимое удалено Содержимое добавлено
Нет описания правки
Строка 24:
 
=== А не все ли равно? ===
Оказывает ли следование закону Деметры (каким бы хорошим он не был сточки зрения теории) реальную помощь в создании программ, более простых в сопровождении? Исследования показали, что классы в языке C++ с большими совокупностями откликов менее ошибкоустойчивы, чем классы с небольшими совокупностями (совокупность откликов представляет собой число функций, непосредственно вызываемых методами конкретного класса). Поскольку следование закону Деметры уменьшает размер совокупности отклика в вызывающем отклике, то классы, спроектированные данным образом, также будут менее склонны к наличию ошибок. Использование закона Деметры сделает вашу программу более адаптируемой и устойчивой, но не бесплатно: будучи «генеральным подрядчиком», ваша программа должна непосредственно делегировать полномочия и управлять всеми существующими субподрядчиками, не привлекая к этому клиентов вашего модуля. На практике это означает, что вы будете создавать большое количество методов-оболочек, которые просто направляют запрос далее к делегату. Эти методы-оболочки влекут за собой расходы во время исполнения и накладные расходы дискового пространства, которые могут оказаться весьма значительными, а для некоторых приложений даже запредельными. Как и при использовании любой методики, вы должны взвесить все «за» и «против» для конкретного приложения. В проекте схемы базы данных обычной практикой является «денормализация» схемы для улучшения производительности: нарушение правил нормализации в обмен на скорость выполнения. Подобного же компромисса можно достичь и в этом случае. На самом деле, обращаясоблюдая закон Деметры и плотно связывая несколько модулей, вы можете получить существенный выигрыш в производительности. Ваша конструкция работает прекрасно, пока она известна и приемлема для этих связываемых модулей.
 
=== Физическая несвязанность ===