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

Возьмем метод из листинга 2.1. Нужен ли переменным более содержательный контекст? Имя функции определяет только часть контекста; алгоритм предоставляет все остальное. При чтении функции становится видно, что три переменные number, verb и pluralModifier являются компонентами сообщения guessМessage. К сожалению, контекст приходится вычислять. При первом взгляде на метод смысл переменных остается неясным.

Листинг 2.1. Переменные с неясным контекстом

private void printGuessStatistics(char candidate, int count) {

    String number;

    String verb;

    String pluralModifier;

    if (count == 0) {

      number = "no";

      verb = "are";

      pluralModifier = "s";

    } else if (count == 1) {

      number = "1";

      verb = "is";

      pluralModifier = "";

Листинг 2.1 (продолжение)

    } else {

      number = Integer.toString(count);

      verb = "are";

      pluralModifier = "s";

    }

    String guessMessage = String.format(

      "There %s %s %s%s", verb, number, candidate, pluralModifier

    );

    print(guessMessage);

  }

Функция длинновата, а переменные используются на всем ее протяжении. Чтобы разделить функцию на меньшие смысловые фрагменты, следует создать класс GuessStatisticsMessage и сделать три переменные полями этого класса. Тем самым мы предоставим очевидный контекст для трех переменных — теперь абсолютно очевидно, что эти переменные являются частью GuessStatisticsMessage. Уточнение контекста также позволяет заметно улучшить четкость алгоритма за счет его деления на меньшие функции (листинг 2.2).

Листинг 2.2. Переменные с контекстом

public class GuessStatisticsMessage {

  private String number;

  private String verb;

  private String pluralModifier;

  public String make(char candidate, int count) {

    createPluralDependentMessageParts(count);

    return String.format(

      "There %s %s %s%s",

       verb, number, candidate, pluralModifier );

  }

  private void createPluralDependentMessageParts(int count) {

    if (count == 0) {

      thereAreNoLetters();

    } else if (count == 1) {

      thereIsOneLetter();

    } else {

      thereAreManyLetters(count);

    }

  }

  private void thereAreManyLetters(int count) {

    number = Integer.toString(count);

    verb = "are";

    pluralModifier = "s";

  }

  private void thereIsOneLetter() {

    number = "1";

    verb = "is";

    pluralModifier = "";

  }

  private void thereAreNoLetters() {

    number = "no";

    verb = "are";

    pluralModifier = "s";

  }

}

Не добавляйте избыточный контекст

Если вы работаете над вымышленным приложением «Gas Station Deluxe», не стоит снабжать имя каждого класса префиксом GSD. В сущности, вы работаете против собственного инструментария. Введите букву «G», нажмите клавишу завершения — и вы получите длинный-предлинный список всех классов в системе. Разумно ли это? IDE пытается помочь вам, так стоит ли ей мешать?

Допустим, вы изобрели класс MailingAddress в учетном модуле GSD и присвоили ему имя GSDAccountAddress. Позднее адрес используется в приложении, обеспечивающем связь с клиентами. Будете ли вы использовать GSDAccountAddress? Насколько подходящим выглядит это имя? Десять из 17 символов либо избыточны, либо не относятся к делу.

Короткие имена обычно лучше длинных, если только их смысл понятен читателю кода. Не включайте в имя больше контекста, чем необходимо.

Имена accountAddress и customerAddress хорошо подходят для экземпляров класса Address, но для классов такой выбор неудачен. Address — вот хорошее имя класса. Если потребуется подчеркнуть различия между MAC-адресами, адресами портов и веб-адресами, я подумаю об использовании имен PostalAddress, MAC и URI. Полученные имена становятся более точными, а это, собственно, и является главной целью всего присваивания имен.

Несколько слов напоследок