Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

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

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

}

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

Поэтому мы говорим: "Долой подробности!". Уберите их из программы. В этом случае мы можем сделать нашу программу гибкой при настройке и легко адаптирующейся к изменениям.

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

Подсказка 37: Осуществляйте настройку, а не интеграцию

Используйте метаданные для спецификации вариантов настройки приложения: подгонки параметров, глобальных параметров пользователя, каталога, в который производится установка приложения, и т. д.

Так что же такое метаданные? Строго говоря, метаданные – это данные о данных. Наиболее распространенным примером, вероятно, является схема базы данных или словарь данных. Схема содержит данные, которые описывают поля (столбцы) в терминах имен, длины и других атрибутов. Вы должны иметь возможность доступа к этой информации и ее обработки так, как если бы это были любые другие данные в этой базе.

Мы используем этот термин в самом широком смысле. Метаданные – это любые данные, которые описывают приложение – как оно выполняется, какие ресурсы обязано использовать и т. д. Обычно доступ к данным и их использование осуществляется на этапе выполнения, а не компиляции. Вы используете метаданные все время, по крайней мере, это делают ваши программы. Предположим, вы щелкаете мышью для того, чтобы скрыть панель инструментов в интернет-браузере. Браузер будет сохранять эти глобальные параметры как метаданные в своего рода внутренней базе данных.

Эта база данных может быть сформирована в собственном формате или может воспользоваться стандартным механизмом. При работе в операционной системе Windows таким механизмом является либо файл инициализации (используется суффикс .ini), либо записи в системном реестре. При работе с Unix подобная функциональная возможность обеспечивается системой X Window с помощью файлов Application Default. Java использует файлы Property. Во всех этих средах для извлечения значения вы указываете ключ. В других, более мощных и гибких реализациях метаданных используется встроенный язык сценариев (см. "Языки, отражающие специфику предметной области").