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

Внимательно выбирайте имена методов

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

Не перебарщивайте с удобными методами

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

Избегайте длинных списков аргументов

Методы, которые принимают много параметров, полны проблем. Несмотря на то, что современные IDE могут помочь нам на этом пути, они все равно могут привести к путанице, и у вас не всегда может быть IDE, которая поможет вам узнать, что такое параметры (например, в вашем инструменте управления исходным кодом во время проверки кода и т.п.). Мы должны стараться, чтобы наши списки аргументов не превышали четырех параметров, а лучше двух или меньше. Еще кое-что, что может ухудшить ситуацию, — это несколько параметров одного типа. Когда параметры имеют один и тот же тип, перестановка аргументов тривиальна, и компилятор, к сожалению, не может нам помочь, когда это происходит. Рассмотрим некоторые варианты:

  • Разбейте метод на несколько методов с меньшим количеством параметров. Там, где эти более мелкие методы могут иметь смысл и работать сами по себе, это может быть отличным вариантом.
  • Создание вспомогательного класса. Когда одна и та же группа параметров передается различным методам, это может быть полезным процессом. Вы создаете объект значения, который просто содержит значения, и используете построитель или сеттеры, чтобы установить для него значения перед передачей в методы.
  • Метод компоновщика: это, вероятно, самый необычный тип. Это небольшое изменение в шаблоне построителя, где вместо создания объекта он используется для вызова метода. Для сбора информации можно использовать различные методы, и тогда последним методом будет execute() (вместо build() для билдера). В этот момент параметры будут проверяться на достоверность и выполняться бизнес-логика. Это интересная система, и я не уверен, что нашел подходящее место для использования этого шаблона.

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

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

public enum Scale {
  CELSIUS, FAHRENHEIT
}

Это обеспечивает более четкие вызовы методов, в то же время допуская расширение до других значений, таких как KELVIN когда-нибудь.