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

List employees = getEmployees();

for(Employee e : employees) {

  totalPay += e.getPay();

}

К счастью, в Java существует метод Collections.emptyList(), который возвращает заранее определенный неизменяемый список, и мы можем воспользоваться им для своих целей:

public List getEmployees() {

  if( .. there are no employees .. )

    return Collections.emptyList();

}

Такое решение сводит к минимуму вероятность появления NullPointerException, а код становится намного чище.

Не передавайте null

Возвращать null из методов плохо, но передавать null при вызове еще хуже. По возможности избегайте передачи null в своем коде (исключение составляют разве что методы сторонних API, при вызове которых без нее не обойтись).

Следующий пример поясняет, почему не следует передавать null. Возьмем простой метод для вычисления метрики по двум точкам:

public class MetricsCalculator

{

  public double xProjection(Point p1, Point p2) {

    return (p2.x — p1.x) * 1.5;

  }

  …

}

Что произойдет, если при вызове будет передан аргумент null?

calculator.xProjection(null, new Point(12, 13));

Конечно, возникнет исключение NullPointerException.

Как исправить его? Можно создать новый тип исключения и инициировать его в методе:

public class MetricsCalculator

{

  public double xProjection(Point p1, Point p2) {

    if (p1 == null || p2 == null) {

      throw InvalidArgumentException(

        "Invalid argument for MetricsCalculator.xProjection");

    }

    return (p2.x — p1.x) * 1.5;

  }

}

Стало лучше? Пожалуй, лучше, чем NullPointerException, но вспомните: для InvalidArgumentException приходится определять обработчик. Что должен делать этот обработчик? Возьметесь предложить хорошую идею?

Существует другая альтернатива: можно воспользоваться набором проверочных директив assert:

public class MetricsCalculator

{

  public double xProjection(Point p1, Point p2) {

    assert p1 != null : "p1 should not be null";

    assert p2 != null : "p2 should not be null";

    return (p2.x — p1.x) * 1.5;

  }

}

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

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

Заключение

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

Литература

[Martin]: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall, 2002.

Глава 8. Границы

Джеймс Гренинг

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

Использование стороннего кода

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