Чи є якісь умови замовлення методу Java? [зачинено]

159

Закрито . Це питання має бути більш зосередженим . Наразі відповіді не приймаються.

Хочете вдосконалити це питання? Оновіть питання, щоб він зосередив увагу на одній проблемі лише редагуючи цю публікацію .

Закрито 6 років тому .

Удосконаліть це питання

У мене великий клас (40 методів), який є частиною пакету, який я буду подавати як курсову роботу. В даний час методи досить сильно змішані з точки зору корисності публічного / приватного тощо. Я хочу замовити їх у розумному вигляді. Чи існує стандартний спосіб цього зробити? Наприклад, поля перераховані перед методами, конструктор (и) перелічені перед іншими методами, а getters / setters - останніми; як щодо решти методів?

java methods conventions

— Фредлі
джерело

Також зауважте, що при роботі з таким кодом більшість IDE дозволяють автоматично бачити визначення того, що знаходиться під курсором. Це означає, що вам не потрібно нічого робити, окрім погляду.

— Thorbjørn Ravn Andersen

Якщо у вас в одному класі 40 методів - ви робите це неправильно

— Бен

132

Деякі конвенції перераховують спочатку всі публічні методи, а потім усі приватні - це означає, що API легко відокремити від реалізації, навіть якщо немає інтерфейсу, якщо ви розумієте, що я маю на увазі.

Інша ідея полягає в тому, щоб групувати пов'язані методи разом - це полегшує виявлення швів, де ви могли б розділити існуючий великий клас на кілька менших, більш цільових.

— Джон Скіт
джерело

1

+1. Я вважаю за краще сортувати за видимістю. Shame Eclipse не може цього зробити автоматично (він завжди групуватиме всі конструктори разом і всі методи разом.)

— finnw

16

@finnw, подайте звіт про помилку. Звідти, як відомо, реалізовані незнайомі речі.

— Thorbjørn Ravn Andersen

3

@Ben: Мій досвід полягає в тому, що будь-який "ніколи" не буде винятків.

— Джон Скіт

1

@JonSkeet у кількох випадках, коли конвенції про замовлення вже не актуальні, наприклад, тестові класи. Не писати поганий код краще порадити, як упорядкувати поганий код.

— Бен

1

@Ben: Я думаю, що нам доведеться погодитися не погодитися. Я написав код, де дуже природно багато членів, не порушуючи жодних роз'єднань проблем тощо.

— Джон Скіт

121

Класові (статичні) змінні: Спочатку змінні загальнодоступного класу, потім захищені, а потім приватні.
Змінні інстанції: Спочатку загальнодоступні, потім захищені, а потім приватні.
Конструктори
Методи: ці методи повинні бути згруповані за функціональністю, а не за обсягом або доступністю. Наприклад, метод приватного класу може знаходитися між двома методами публічного примірника. Мета - полегшити читання та розуміння коду.

Джерело: http://www.oracle.com/technetwork/java/codeconventions-141855.html

— Майкл
джерело

4

Це 15-річна вірогідність і, мабуть, трохи застаріла з появою сучасних

— ІДЕ

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

Не впевнений, чи є загальновизнаний стандарт, але мої власні переваги є;

спочатку конструктори
Далі статичні методи, якщо є основний метод, завжди перед іншими статичними методами
Далі нестатичні методи, як правило, в порядку значущості методу, за яким слід застосовувати будь-які методи, які він викликає. Це означає, що загальнодоступні методи, що викликають інші методи класу, з'являються у напрямку до верху, а приватні методи, які не викликають жодних інших методів, зазвичай закінчуються донизу
стандартні методи , такі як toString, equalsі hashcodeнаступний
геттери та сетери мають спеціальне місце, відведене внизу класу

— Qwerky
джерело

Я дійсно віддаю перевагу останнім конструкторам, тому що правильно написаний конструктор повинен робити зовсім мало, ніж привласнювати свої аргументи властивостям.

— GordonM

@GordonM Чому ти так вважаєш? Я б пішов так далеко, щоб стверджувати, що зворотна правда. Ви завжди повинні думати про найчистіший API для своїх класів. І це часто не так, як вони зберігаються, тому я часто роблю трохи обробку, щоб позбавити абонента від цього тягаря

— Нейрон,

@GordonM Я не говорю про побічні ефекти. Тож жодних змін у прийнятих списках чи нічого подібного не було. Просто передача та встановлення значень вимагає, щоб Клас багато розповів вам про його реалізацію, що не повинно бути так

— Нейрон

@LonelyNeuron Я не зовсім впевнений, що ви тут говорите, але, схоже, ви говорите, що конструктор повинен багато працювати над налаштуваннями, крім присвоєння своїх аргументів внутрішньому стану. Це, безумовно, неправильно, адже це означає, що справи відбуваються «магічно». Заклик до new Thing()повинен призвести лише до того, що нова штука буде створена. Це не повинно спричиняти відкриття підключень до бази даних, записування файлів тощо тощо

— GordonM

@LonelyNeuron Наявність залежностей у конструкторі нічого не говорить про реалізацію класу, окрім того, якими є його залежності. Це гарна річ, не погана.

— GordonM

12

40 методів в одному класі - це небагато.

Чи має сенс перенести частину функціональних можливостей в інші - відповідно названі - класи. Тоді це набагато простіше зрозуміти.

Коли їх менше, набагато простіше перерахувати їх у природному порядку читання. Часта парадигма - перераховувати речі до або після того, як вони вам потрібні, у тому порядку, який вам потрібен.

Зазвичай це означає, що main()йде зверху чи знизу.

— Торбьорн Равн Андерсен
джерело

1

ти

— маєш

4

У вас не завжди є вибір, наприклад, якщо ви реалізуєте інтерфейс з безліччю методів.

— finnw

5

Це Android-активність, тому є безліч, які просто не можуть більше нікуди йти onPause()і onResume()т. Д., А також усі мої OnClickListenerполя, які, хоч і поля, не виглядають і не поводяться так, як вони, тому це розумно перерахуйте їх окремо.

— Фредлі

@finnw, абстрактні заняття є приємними і корисними для цієї мети.

— Thorbjørn Ravn Andersen

11

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

— eljenso
джерело

2

Також eclipse пропонує можливість сортувати членів класу для вас, якщо ви з якоїсь причини змішали їх:

Відкрийте файл класу, у головному меню перейдіть до "Джерело" та виберіть "Сортувати учасників".

взято звідси: Методи сортування в Eclipse

— Стефан Ріхтер
джерело

1

Ви використовуєте Eclipse? Якщо так, я б дотримувався порядку сортування за замовчуванням для учасників, тому що це, ймовірно, найбільше знайоме тому, хто читає ваш код (хоча це не мій улюблений порядок сортування.)

— finnw
джерело