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

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

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

Обобщенные директивы импорта иногда становятся причиной конфликтов имен и неоднозначностей. Два класса с одинаковыми именами, находящиеся в разных пакетах, должны импортироваться конкретными директивами (или по крайней мере их имена должны уточняться при использовании). Это создает определенные неудобства, однако ситуация встречается достаточно редко, так что в общем случае обобщенные директивы импорта все равно лучше конкретных.

J2: Не наследуйте от констант

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

public class HourlyEmployee extends Employee {

  private int tenthsWorked;

  private double hourlyRate;

  public Money calculatePay() {

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

    int overTime = tenthsWorked - straightTime;

    return new Money(

      hourlyRate * (tenthsWorked + OVERTIME_RATE * overTime)

    );

  }

  ...

}

Где определяются константы TENTHS_PER_WEEK и OVERTIME_RATE? Возможно, в классе Employee; давайте посмотрим:

public abstract class Employee implements PayrollConstants {

  public abstract boolean isPayday();

  public abstract Money calculatePay();

  public abstract void deliverPay(Money pay);

}

Нет, не здесь. А где тогда? Присмотритесь повнимательнее к классу Employee. Он реализует интерфейс PayrollConstants.

public interface PayrollConstants {

  public static final int TENTHS_PER_WEEK = 400;

  public static final double OVERTIME_RATE = 1.5;

}

Совершенно отвратительная привычка! Константы скрыты на верхнем уровне иерархии наследования. Брр! Наследование не должно применяться для того, чтобы обойти языковые правила видимости. Используйте статическое импортирование.

import static PayrollConstants.*;

public class HourlyEmployee extends Employee {

  private int tenthsWorked;

  private double hourlyRate;

  public Money calculatePay() {

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

    int overTime = tenthsWorked - straightTime;

    return new Money(

      hourlyRate * (tenthsWorked + OVERTIME_RATE * overTime)

    );

  }

  ...

}

J3: Константы против перечислений

В языке появились перечисления ( Java 5) — пользуйтесь ими! Не используйте старый трюк с public static final int. Смысл int может потеряться; смысл перечислений потеряться не может, потому что они принадлежат указанному перечислению.

Тщательно изучите синтаксис перечислений. Не забудьте, что перечисления могут содержать методы и поля. Это очень мощные синтаксические инструменты, значительно превосходящие int по гибкости и выразительности. Рассмотрим следующую разновидность кода начисления зарплаты:

public class HourlyEmployee extends Employee {

  private int tenthsWorked;

  HourlyPayGrade grade;

  public Money calculatePay() {