димости гораздо сложнее сжать, чем расширить - иначе говоря, превратить глобальную переменную в переменную класса сложнее, чем наоборот. Защищенные данные-члены класса также сложнее превратить в закрытые, чем закрытые в защищенные. Так что, если сомневаетесь, выбирайте наименьшую возможную область видимости переменной: попытайтесь сделать переменную локальной для отдельного цикла, локальной для конкретного метода, затем - закрытой переменной класса, затем - защищенной, далее попробуйте включить ее в пакет (если ваш язык программирования поддерживает пакеты) и лишь в крайнем случае сделайте ее глобальной.

Комментарии по поводу минимизации области видимости

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

Другие предпочитают делать переменные как можно более Певекреш»! ««ый1со Идея мй*

нймйзацйи области &ттош -вокальными, потому что локальная область видимости спо-свшт с идеей сокрытия т- собствует интеллектуальной управляемости. Чем больше формаций [см, подраздел информации вы скрыли, тем меньше вам нужно удерживать «Скрывайте секреты (к вопро* в уме в каждый конкретный момент времени и тем ниже су о сокрытйи информации)» вероятность того, что вы допустите ошибку, забыв одну из раздела 5.3.

многих деталей, о которых нужно было помнить.

Разница между философией «удобства» и философией «интеллектуальной управляемости» сводится к различию между ориентацией на написание программы и ориентацией на ее чтение. Максимизация области видимости может облегчить написание программы, но программу, в которой каждый метод может вызвать любую переменную в любой момент времени, сложнее понять, чем код, основанный на грамотно организованных методах. Сделав данные глобальными, вы не сможете ограничиться пониманием работы одного метода: вы должны будете понимать работу всех других методов, которые вместе с ним используют те же глобальные данные. Подобные программы сложно читать, сложно отлаживать и сложно изменять.

Пврекреошя шша О методах ™ ограничивайте область видимости каждой перемен-доступа см. подаздел «Йсполь- минимальным фрагментом кода. Можете ограничить ее

зова«ие методов доступа ть- одним циклом или одним методом - великолепно! Не посте глобальных данных»» раде- лучается - ограничьте область видимости методами одно-

то класса. Если и это невозможно, создайте методы доступа, позволяющие использовать переменную совместно с другими классами. «Голые» глобальные данные требуются редко, если вообще такое бывает.

10.5. Персистентность

«Персистентность» - это еще одно слово, характеризующее длительность существования данных. Персистентность принимает несколько форм. Некоторые переменные «живут»:

пока выполняется конкретный блок кода или метод: например, это переменные, объявленные внутри цикла for языка С++ или Java;

столько, сколько вы им позволяете: в Java переменные, созданные при помощи оператора new, «живут» до сборки мусора; в С++ созданные аналогично переменные существуют, пока не будут уничтожены с помощью оператора delete-,

до завершения программы: этому описанию соответствуют глобальные переменные в большинстве языков, а также статические переменные в языках С++ и Java;

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

Главная проблема персистентности возникает, когда вы предполагаете, что переменная существует дольше, чем есть на самом деле. Переменная похожа на пакет молока в холодильнике. Предполагается, что он может храниться неделю. Иногда он хранится месяц, и с молоком ничего не происходит, а иногда молоко скисает через пять дней. Переменная может быть столь же непредсказуема. Если вы попытаетесь использовать значение переменной после окончания нормальной длительности ее существования, получите ли вы ее прежнее значение? Иногда значение переменной «скисает», и вы получаете ошибку. В других случаях компилятор оставляет старое значение неизменным, позволяя вам воображать, что все нормально.

Проблем подобного рода можно избежать.

Включайте в программу отладочный код или утвержде-

ния для проверки важных переменных на предмет до-

пустимости их значений. Если значения недопустимы, доступа (см. пойраздел

отображайте предупреждение, рекомендующее присту- «Преимущества методов досту-пить к поиску кода неверной инициализации. з» раздела 13.3).

Завершив работу с переменными, присваивайте им «недопустимые значения». Скажем, после освобождения памяти при помощи оператора delete вы может установить указатель в null

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

Выработайте привычку объявлять и инициализировать все данные перед их использованием. Если видите обращение к данным, но не можете найти поблизости команду их инициализации, отнеситесь к этому с подозрением!

10.6. Время связывания

Одним из аспектов инициализации, серьезно влияющим на удобство сопровождения и изменения программы, является «время связывания» - момент, когда переменная и ее значение связываются вместе (Thimbleby, 1988). Связываются ли они при написании кода? При его компиляции? При загрузке? При выполнении программы? В другое время?

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

Пример связывания во время написания кода (Java)

titleBar.color = OxFF; OxFF - шестнадцатеричное значение синего цвета

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

В следующем примере связывание переменной выполняется чуть Позднее, во время компиляции кода:

Пример связывания во время компиляции (Java)

private static final int COLOR BLUE = OxFF;

private static final int TITLE BAR COLOR = COLOR BLUE;

titleBar.color = TITLE BAR COLOR;

В данном случае TITLE BARCOLOR является именованной константой - выражением, вместо которого компилятор подставляет конкретное значение при компиляции. Этот подход почти всегда лучше, чем жесткое кодирование. Он облегчает чтение кода, потому что имя константы TITLE BAR COLOR лучше характеризует представляемое ей значение, чем OxFF. Он облегчает изменение цвета заголовка окна (title bar), так как изменение константы будет автоматически отражено во всех местах, где она используется. При этом он не приводит к снижению быстродействия программы в период выполнения.

Вот пример еще более позднего связывания - в период выполнения:

Пример связывания в период выполнения (Java)

titleBar.color = ReaclTitleBarColor();

ReadTitleBarColorQ - это метод, который во время выполнения программы читает значение из реестра Microsoft Windows, файла свойств Java или подобного места.

Этот код более понятен и гибок, чем код с жестко закодированным значением. Чтобы изменить значение titleBar.color, вам не нужно изменять программу: достаточно просто изменить содержание файла, из которого метод ReadTitleBarColorQ