В этой главе мы рассмотрим множество различных советов по правильному проектированию методов. Методы – это то, с чем мы будем взаимодействовать каждый день, поэтому хороший дизайн методов чрезвычайно важен.
Тщательно Выбирайте Имена Методов Имена методов часто являются первым, с чем мы будем взаимодействовать при использовании фрагмента кода. Наличие хорошего описательного названия может облегчить поиск метода, который мы ищем, а также служить простой документацией. При написании имен наших методов нам нужно провести грань между слишком краткими именами и слишком длинными методами. Лично я думаю, что ошибка на стороне дольше, вероятно, стоит вашего времени.
Не переусердствуйте в предоставлении удобных методов Эти советы больше касаются длины тел методов. Методы не должны делать слишком много (принцип единой ответственности), но они также должны делать что-то значимое и в целом полезное. Это вдвойне относится к интерфейсам, где разработчики вынуждены реализовывать методы, которые мы определяем.
Избегайте длинных списков аргументов Методы, которые принимают много параметров, полны проблем. Несмотря на то, что современные IDE могут помочь нам на нашем пути, это все равно может привести к путанице, и у вас не всегда может быть IDE, которая поможет вам узнать, что такое параметры (например, в вашем инструменте управления версиями во время проверки кода и тому подобное). Мы должны стремиться к тому, чтобы наши списки аргументов ограничивались четырьмя параметрами и ниже, предпочтительно двумя или меньше. Что-то еще, что также может ухудшить ситуацию, – это несколько параметров одного и того же типа. Когда параметры имеют один и тот же тип, перенос аргументов тривиален, и компилятор, к сожалению, не может нам помочь, когда это происходит. Давайте рассмотрим несколько вариантов:
- Давайте рассмотрим несколько вариантов: Давайте рассмотрим несколько вариантов: Давайте рассмотрим несколько вариантов:
- Давайте рассмотрим несколько вариантов: Это небольшое изменение в шаблоне builder, где вместо создания объекта он используется для вызова метода. Для сбора информации можно использовать различные методы, и тогда последним методом будет execute()
- (вместо build()
для builder). В этот момент параметры будут проверены на достоверность и будет выполнена бизнес-логика. Это интересная система, и я не уверен, что нашел отличное место для использования этого шаблона.
Используйте Интерфейсы в качестве параметров, а не классов Это в значительной степени связано со многим из того, о чем мы говорили в предыдущих главах. Мы должны предоставлять и принимать интерфейсы там, где они доступны, а не в конкретных классах. В принципе, нет причин иметь тип аргумента, который указывает конкретный класс, а не интерфейс.
Предпочитайте перечисления из двух элементов логическим значениям Это интересный вопрос, но для меня он имеет смысл. Например, если у нас есть метод, который предоставляет температуры и может предоставлять их в разных масштабах, а не принимать параметр типа Исцелций мы должны создать следующее перечисление:
public enum Scale {
CELSIUS, FAHRENHEIT
}
Это позволяет выполнять более четкие вызовы методов, сохраняя при этом возможность расширения до других значений, таких как КЕЛЬВИН когда-нибудь.
Оригинал: “https://dev.to/kylec32/effective-java-design-method-signatures-carefully-5fm5”