Существуют ли соглашения о порядке использования методов Java? [закрыто]

159

У меня есть большой класс (около 40 методов), который является частью пакета, который я буду отправлять как курсовую работу. В настоящее время методы довольно сложны с точки зрения полезности общего / частного и т. Д., И я хочу их разумно упорядочить. Есть ли стандартный способ сделать это? Например, обычно поля перечисляются перед методами, конструктор (ы) перечисляются перед другими методами, а getters / setters последними; как насчет остальных методов?

java methods conventions fredley
источник
Также обратите внимание, что при работе с кодом, подобным этому, большинство IDE позволяют вам автоматически видеть определение того, что находится под курсором. Это означает, что вам не нужно ничего делать, кроме взгляда.
Торбьерн Равн Андерсен
Если у вас есть 40 методов в одном классе - вы делаете это неправильно
Бен

Ответы:

132

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

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

Джон Скит
источник
1
+1. Я предпочитаю сортировать по видимости. Позор Eclipse не может сделать это автоматически (он всегда будет группировать все конструкторы и все методы вместе)
finnw
16
@finnw, подайте отчет об ошибке. Странные вещи, как известно, были реализованы оттуда.
Торбьерн Равн Андерсен
3
@ Бен: Мой опыт показывает, что у любого «никогда» не будет исключений.
Джон Скит
1
@JonSkeet в некоторых случаях, когда соглашения о порядке больше не актуальны, например, тестовые классы. Не писать плохой код лучше советовать, чем устраивать плохой код.
Бен
1
@ Бен: Я думаю, что мы должны согласиться не согласиться. Я написал код, в котором очень естественно много членов, не нарушая разделения интересов и т. Д.
Джон Скит,
121

  1. Классовые (статические) переменные: сначала общедоступные переменные класса, затем защищенные, а затем приватные.

  2. Переменные экземпляра: сначала общедоступные, затем защищенные, а затем частные.

  3. Конструкторы

  4. Методы: эти методы должны быть сгруппированы по функциональности, а не по объему или доступности. Например, метод закрытого класса может находиться между двумя открытыми методами экземпляра. Цель - облегчить чтение и понимание кода.

Источник: http://www.oracle.com/technetwork/java/codeconventions-141855.html

Майкл
источник
4
Это 15-летний и, вероятно, немного устарел с появлением современных IDE ...
assylias
16
@assylias: IMO, читаемость не зависит от IDE. Держать публику перед личностью обычно лучше.
Saurabheights
40

Более точная ссылка на «Условные обозначения кода»: «Объявления классов и интерфейсов»

Тимофей Горшков
источник
8
+1, afaik - это ЕДИНСТВЕННЫЙ пост, который фактически отвечает на вопрос. ДА, существует стандартный порядок, предписанный Oracle и Sun: 1. публичный комментарий, 2. класс, 3. внутренний комментарий, 4. статические данные, 5. данные экземпляра, 6. ctors, 7. методы и внутри каждой группы разделов. по логике, а не по доступности.
Джон Хенкель
@VadimKirilchuk «Интернет-архив» не работает…
Тимофей Горшков
1
oracle.com/technetwork/java/codeconvtoc-136057.html
Старейшина Гик,
15

Не уверен, что существует общепринятый стандарт, но мои собственные предпочтения таковы;

  • сначала конструкторы
  • статические методы затем, если есть метод main, всегда перед другими статическими методами
  • Далее следуют нестатические методы, обычно в порядке значимости метода, за которым следуют любые методы, которые он вызывает. Это означает, что открытые методы, которые вызывают другие методы класса, отображаются сверху, а частные методы, которые не вызывают другие методы, обычно заканчиваются снизу.
  • стандартные методы, такие как toString, equalsа hashcodeзатем
  • геттеры и сеттеры имеют специальное место, зарезервированное прямо внизу класса
Qwerky
источник
Я действительно предпочитаю конструкторы последним, потому что правильно написанный конструктор должен делать совсем немного, кроме как присваивать свои аргументы свойствам.
GordonM
@GordonM Почему ты так думаешь? Я бы дошел до того, что докажу обратное. Вы всегда должны думать о самом чистом API для ваших классов. И это часто не то, как они хранятся, поэтому я часто делаю немного обработки, чтобы освободить абонента от этого бремени
Нейрон
@GordonM Я не говорю о побочных эффектах. Так что никаких изменений в списках, которые были переданы или что-то подобное. Просто передача и установка значений требует, чтобы класс много говорил вам о его реализации, чего не должно быть
Neuron
@LonelyNeuron Я не совсем уверен, что вы говорите здесь, но похоже, что вы говорите, что конструктор должен выполнить большую работу по настройке, кроме присвоения своих аргументов внутреннему состоянию. Это совершенно определенно неправильно, потому что это означает, что все происходит "магией". Призыв new Thing()должен привести только к созданию новой вещи. Это не должно приводить к открытию соединений с базой данных, записи файлов и т. Д. И т. Д.
GordonM
@LonelyNeuron Наличие зависимостей в конструкторе ничего не говорит вам о реализации класса, кроме его зависимостей. Это хорошо, а не плохо.
GordonM
12

40 методов в одном классе - это много.

Имеет ли смысл перенести некоторые функциональные возможности в другие - с подходящими именами - классы. Тогда это намного легче понять.

Когда их меньше, их намного проще перечислить в естественном порядке чтения. Частая парадигма - перечислять вещи до или после того, как они вам нужны, в том порядке, в котором они вам нужны.

Обычно это означает, что main()идет сверху или снизу.

Турбьерн Равн Андерсен
источник
1
вы так правы - это не вопрос заказа
kostja
4
У вас не всегда есть выбор, например, если вы реализуете интерфейс с большим количеством методов.
finnw
5
Это Android активность, так что есть много , что просто не может пойти куда - нибудь еще, onPause(), и onResume()т.д., а также все мои OnClickListenerполя, которые, хотя они и являются поля, не смотрят или ведут себя , как их , так что это разумно перечислите их отдельно.
Фредли
@finnw, абстрактные классы хороши и пригодны для этой цели.
Торбьерн Равн Андерсен
11

Мое "соглашение": статическое перед экземпляром, публичное перед приватным, конструктор перед методами, но основной метод внизу (если есть).

eljenso
источник
2

Кроме того, eclipse предлагает возможность сортировать участников класса, если вы по какой-то причине перепутали их:

Откройте ваш файл класса, перейдите к «Source» в главном меню и выберите «Sort Members».

взяты отсюда: методы сортировки в Eclipse

Стефан Рихтер
источник
1

Вы используете Eclipse? Если это так, я бы придерживался порядка сортировки членов по умолчанию, потому что он, вероятно, наиболее знаком тем, кто читает ваш код (хотя это не мой любимый порядок сортировки.)

finnw
источник