Чистый код. Создание, анализ и рефакторинг

Если в функцию включена переменная response для хранения данных HttpServletResponse, будьте последовательны и используйте такое же имя переменной в других функциях, работающих с объектами HttpServletResponse. Если метод называется processVerificationRequest, присваивайте похожие имена (например, processDeletionRequest) методам, обрабатывающим другие запросы.

Последовательное соблюдение подобных схем и правил существенно упрощает чтение и модификацию кода.

G12: Балласт

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

G13: Искусственные привязки

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

В общем случае искусственной считается привязка между двумя модулями, не имеющая явной, непосредственной цели. Искусственная привязка возникает в результате размещения переменной, константы или функции во временно удобном, но неподходящем месте. Главные причины для появления искусственных привязок — лень и небрежность.

Не жалейте времени — разберитесь, где должно располагаться объявление той или иной функции, константы или переменной. Слишком часто мы размещаем их в удобном месте «под рукой», а потом оставляем там навсегда.

G14: Функциональная зависть

Это один из «запахов кода», описанных у Мартина Фаулера [Refactoring]. Для методов класса должны быть важны переменные и функции того класса, которому они принадлежат, а не переменные и функции других классов. Когда метод использует методы доступа другого объекта для манипуляций с его данными, то он завидует области видимости класса этого объекта. Он словно мечтает находиться в другом классе, чтобы иметь прямой доступ к переменным, с которыми он работает. Пример:

public class HourlyPayCalculator {

  public Money calculateWeeklyPay(HourlyEmployee e) {

    int tenthRate = e.getTenthRate().getPennies();

    int tenthsWorked = e.getTenthsWorked();

    int straightTime = Math.min(400, tenthsWorked);

    int overTime = Math.max(0, tenthsWorked - straightTime);

    int straightPay = straightTime * tenthRate;

    int overtimePay = (int)Math.round(overTime*tenthRate*1.5);

    return new Money(straightPay + overtimePay);

  }

}

Метод calculateWeeklyPay обращается к объекту HourlyEmployee за данными для обработки. Метод calculateWeeklyPay завидует области видимости HourlyEmployee. Он «желает» получить доступ к внутренней реализации HourlyEmployee.

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

public class HourlyEmployeeReport {

  private HourlyEmployee employee ;

  public HourlyEmployeeReport(HourlyEmployee e) {

    this.employee = e;

  }

  String reportHours() {

    return String.format(

      «Name: %s\tHours:%d.%1d\n»,

      employee.getName(),

      employee.getTenthsWorked()/10,

      employee.getTenthsWorked()%10);

  }

}

Очевидно, метод reportHours завидует классу HourlyEmployee. С другой стороны, мы не хотим, чтобы класс HourlyEmployee знал о формате отчета. Перемещение форматной строки в класс HourlyEmployee нарушает некоторые принципы объектно-ориентированного проектирования[74]. Такое размещение привязывает HourlyEmployee к формату отчета и делает его уязвимым для изменений в этом формате.

G15: Аргументы-селекторы