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

Воплощайте архитектурные решения на уровне структуры кода; она важнее стандартов и конвенций. Содержательные имена полезны, но структура, заставляющая пользователя соблюдать установленные правила, важнее. Например, конструкции switch/case с хорошо выбранными именами элементов перечисления уступают базовым классам с абстрактными методами. Ничто не вынуждает пользователя применять одинаковую реализацию switch/case во всех случаях; с другой стороны, базовые классы заставляют его реализовать все абстрактные методы в конкретных классах.

G28: Инкапсулируйте условные конструкции

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

if (shouldBeDeleted(timer))

выразительнее команды

if (timer.hasExpired() && !timer.isRecurrent())

G29: Избегайте отрицательных условий

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

if (buffer.shouldCompact())

предпочтительнее записи

if (!buffer.shouldNotCompact())

G30: Функции должны выполнять одну операцию

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

Пример:

public void pay() {

  for (Employee e : employees) {

    if (e.isPayday()) {

      Money pay = e.calculatePay();

      e.deliverPay(pay);

    }

  }

}

Эта функция выполняет сразу три операции: она перебирает всех работников; проверяет, начислены ли работнику какие-то выплаты; и наконец, производит оплату. Код лучше записать в следующем виде:

public void pay() {

  for (Employee e : employees)

    payIfNecessary(e);

}

private void payIfNecessary(Employee e) {

  if (e.isPayday())

    calculateAndDeliverPay(e);

}

private void calculateAndDeliverPay(Employee e) {

  Money pay = e.calculatePay();

  e.deliverPay(pay);

}

Каждая из этих функций выполняет только одну операцию (см. «Правило одной операции», с. 59).

G31: Скрытые временны́е привязки

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

public class MoogDiver {

  Gradient gradient;

  List splines;

  public void dive(String reason) {

    saturateGradient();

    reticulateSplines();

    diveForMoog(reason);

  }

  ...

}

Порядок вызова трех функций важен. Сначала вызывается saturateGradient(), затем reticulateSplines() и только после этого diveForMoog(). К сожалению, код не обеспечивает принудительного соблюдения временной привязки. Ничто не мешает другому программисту вызвать reticulateSplines до saturateGradient, и все кончится исключением UnsaturatedGradientException.

Более правильное решение выглядит так:

public class MoogDiver {

  Gradient gradient;

  List splines;

  public void dive(String reason) {

    Gradient gradient = saturateGradient();

    List splines = reticulateSplines(gradient);

    diveForMoog(splines, reason);

  }

  ...

}

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

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

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

G32: Структура кода должна быть обоснована