У якому порядку визначати геттерів та сетерів? [зачинено]


14

Чи є найкраща практика для того, щоб визначити геттерів та сеттерів? Здається, є дві практики:

  • пари геттер / сетер
  • спочатку геттери, потім сетери (або навпаки)

Щоб висвітлити різницю, ось приклад Java з пар Getter / Setter:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public int getVar2() {
    return var2;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

Ось приклад Java спочатку getters, а потім сетерів:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public int getVar2() {
    return var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

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

Відповіді:


8

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

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

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


Чи хотіли б ви включити будь-який додатковий аргумент, чому функції, що працюють на одних і тих же членів, слід зберігати разом?
NN

Додано деякі причини.
Бенедикт

25

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


7
Погодьтеся повністю. Це відбувається під заголовком «не пітніти маленький матеріал», який повинен бути стандарт кодування правило кожного # 0 (це є правилом # 0 в «C ++ Стандарти кодування» від Herb Sutter і Андре Alexandrescu.)
Девід Hammen

Я впевнений, що люди багато сперечалися, яким пальцем вони повинні скористатися, щоб потрапити на пробіл)))
superM

@Michael Я теж прав. Я спробував використовувати виключно ліву, але це було надзвичайно важко, і моє введення тексту повільно повзало.
axblount

@axblount Я праворуч, але завжди використовую мій великий палець. Я просто спробував моє право і мав той самий досвід, який ви описали. Я також ввожу чомусь лівою рукою "y".
KChaloux

6

Це також може залежати від мови. У Java немає жодної реальної переваги ні для того, ні для замовлення, але, наприклад, у C # у вас є поняття "властивості", які об'єднують гетьтер і сеттер разом, тому він націлює виконання цього замовлення. Такою мовою, як C ++, де ви можете бажати різної видимості на getters vs. setters (наприклад, приватний сеттер, public getter), ви, ймовірно, зробите навпаки, оскільки модифікатор видимості надається один раз для декількох методів, а не індивідуально для кожного .


5

Наскільки мені відомо, немає єдиної конвенції. У розділі Конвенцій коду Java Oracle про організацію файлів прямо не згадується розміщення геттерів та сеттерів, але він говорить:

Ці методи повинні бути згруповані за функціональністю, а не за обсягом або доступністю.

Це не дає ніяких вказівок - я можу стверджувати, що будь-яке місце розташування відповідає цим критеріям.

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

Як приклад, Eclipse подає вигляд "Начерк", який дасть змогу різними способами сортувати та фільтрувати методи та поля, а також переходити до місця, де вони знаходяться у файлах. NetBeans мав подібний функціонал, і я б підозрював, що так само і більшість інших IDE.

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

Найкращим рішенням буде просто послідовність файлів у проекті. Знайдіть стандарт, документуйте його і дотримуйтесь його.


1

Згрупуйте геттер і сетер по одному полі разом, по парах.

Згрупування всіх геттерів разом і всіх сеттерів разом ускладнює визначити, у яких полях є просто геттери чи просто сетери.

Коли я читаю код або шукаю певну функціональність, я вважаю, що клас має поля, при цьому в кожному полі є геттер і сеттер. Немає сенсу для класу мати групу getters та групу сеттерів, у кожному з яких є поля.


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

То, і концептуальна модель того, що таке клас. Заняття повинні бути організовані насамперед за функціональністю. Створюючи клас, ви можете вирішити, що йому потрібно публічно видиме, змінне поле. Це концептуальна "функціональність", а не синтаксичне вираження методами getter та setter.
М. Дадлі

0

Коли-небудь Java IDE може генерувати геттери та сетери для вас. Просто використовуйте цю функціональність і залиште порядок таких методів, як IDE, який її створив. Це генерований код, не торкайтеся його зайвим.


Я про це знаю. Однак, наприклад, у Eclipse можна вибирати між різними замовленнями .
NN

Правильно. Варіант за замовчуванням "Поля в геттерах / сетерах" здається більш корисним, тому що ви можете додати більше полів та генерувати більше додаткових аксесуарів пізніше, не турбуючись, який метод буде куди, просто покладіть обидва в кінці.
користувач281377
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.