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

  protected abstract DayDate _makeDate(int day, DayDate.Month month, int year);

  protected abstract DayDate _makeDate(int day, int month, int year);

  protected abstract DayDate _makeDate(java.util.Date date);

  protected abstract int _getMinimumYear();

  protected abstract int _getMaximumYear();

  public static DayDate makeDate(int ordinal) {

    return factory._makeDate(ordinal);

  }

  public static DayDate makeDate(int day, DayDate.Month month, int year) {

    return factory._makeDate(day, month, year);

  }

  public static DayDate makeDate(int day, int month, int year) {

    return factory._makeDate(day, month, year);

  }

  public static DayDate makeDate(java.util.Date date) {

    return factory._makeDate(date);

  }

  public static int getMinimumYear() {

    return factory._getMinimumYear();

  }

  public static int getMaximumYear() {

    return factory._getMaximumYear();

  }

}

Фабрика заменяет методы createInstance методами makeDate, в результате чего имена выглядят гораздо лучше [N1]. По умолчанию используется SpreadsheetDateFactory, но этот класс можно в любой момент заменить другой фабрикой. Статические методы, делегирующие выполнение операций абстрактным методам, используют комбинацию паттернов СИНГЛЕТ [GOF], ДЕКОРАТОР [GOF] и АБСТРАКТНАЯ ФАБРИКА.

Класс SpreadsheetDateFactory выглядит так:

public class SpreadsheetDateFactory extends DayDateFactory {

  public DayDate _makeDate(int ordinal) {

    return new SpreadsheetDate(ordinal);

  }

  public DayDate _makeDate(int day, DayDate.Month month, int year) {

    return new SpreadsheetDate(day, month, year);

  }

  public DayDate _makeDate(int day, int month, int year) {

    return new SpreadsheetDate(day, month, year);

  }

  public DayDate _makeDate(Date date) {

    final GregorianCalendar calendar = new GregorianCalendar();

    calendar.setTime(date);

    return new SpreadsheetDate(

      calendar.get(Calendar.DATE),

      DayDate.Month.make(calendar.get(Calendar.MONTH) + 1),

      calendar.get(Calendar.YEAR));

  }

  protected int _getMinimumYear() {

    return SpreadsheetDate.MINIMUM_YEAR_SUPPORTED;

  }

  protected int _getMaximumYear() {

    return SpreadsheetDate.MAXIMUM_YEAR_SUPPORTED;

  }

}

Как видите, я уже переместил переменные MINIMUM_YEAR_SUPPORTED и MAXIMUM_YEAR_SUPPORTED в класс SpreadsheetDate, в котором им положено находиться [G6].

Следующая проблема DayDate — константы дней, начинающиеся со строки 109. Их следует оформить в виде другого перечисления [J3]. Мы уже видели, как это делается, поэтому я не буду повторяться. При желании посмотрите в итоговом листинге.

Далее мы видим серию таблиц, начинающуюся с LAST_DAY_OF_MONTH в строке 140. Моя первая претензия к этим таблицам состоит в том, что описывающие их комментарии избыточны [C3]. Одних имен вполне достаточно, поэтому я собираюсь удалить комментарии.

Также неясно, почему эта таблица не объявлена приватной [G8], потому что в классе имеется статическая функция lastDayOfMonth, предоставляющая те же данные.

Следующая таблица, AGGREGATE_DAYS_TO_END_OF_MONTH, выглядит загадочно — она ни разу не используется в JCommon [G9]. Я удалил ее.

То же произошло с LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_MONTH.

Следующая таблица, AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH, используется только в SpreadsheetDate (строки 434 и 473). Так почему бы не переместить ее в SpreadsheetDate? Против перемещения говорит тот факт, что таблица не привязана ни к какой конкретной реализации [G6]. С другой стороны, никаких реализаций, кроме SpreadsheetDate, фактически не существует, поэтому таблицу следует переместить ближе к месту ее использования [G10].