Будуйте як об'єкти на Java

Чи повністю проти Java способу створення об'єктів, подібних структурам?

class SomeData1 {
    public int x;
    public int y;
}

Я бачу клас з аксесуарами та мутаторами, які більше схожі на Java.

class SomeData2 {
    int getX();
    void setX(int x);

    int getY();
    void setY(int y);

    private int x;
    private int y;
}

Клас з першого прикладу нотаційно зручний.

// a function in a class
public int f(SomeData1 d) {
    return (3 * d.x) / d.y;
}

Це не так зручно.

// a function in a class
public int f(SomeData2 d) {
    return (3 * d.getX()) / d.getY();
}

Це поширена тема. Недолік створення публічних полів в об'єктах полягає в тому, що ви не маєте контролю над значеннями, які йому задаються. У групових проектах, де багато програмістів, які використовують один і той же код, важливо уникати побічних ефектів. Крім того, іноді краще повернути копію об’єкта поля або якось перетворити його тощо. Ви можете знущатися над такими методами у своїх тестах. Якщо ви створюєте новий клас, можливо, ви не побачите всіх можливих дій. Це як оборонне програмування - коли-небудь геттери та сетери можуть бути корисними, і створити / використовувати їх не коштує багато. Тому вони іноді корисні.

На практиці більшість полів мають прості геттери та сетери. Можливе рішення виглядатиме так:

public property String foo;   
a->Foo = b->Foo;

Оновлення: Навряд чи підтримка властивостей буде додана в Java 7 або, можливо, коли-небудь. Інші мови JVM, такі як Groovy, Scala тощо, зараз підтримують цю функцію. - Алекс Міллер

Виявляється, що багато людей з Java не знайомі з Посібниками з кодування Sun Java, які говорять, що цілком доречно використовувати загальну змінну екземпляра, коли клас по суті є "Struct", якщо Java підтримує "struct" (коли немає поведінки).

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

Конвенції Java-коду від 1999 року і досі залишаються незмінними.

10.1 Надання доступу до змінних інстанцій та класів

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

Одним із прикладів відповідних змінних публічних примірників є випадок, коли клас по суті є структурою даних без поведінки. Іншими словами, якщо ви використовували б структуру замість класу (якщо підтримка Java підтримувала структуру), то доречно зробити загальнодоступними змінні екземпляра класу .

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#177

http://en.wikipedia.org/wiki/Plain_old_data_structure

http://docs.oracle.com/javase/1.3/docs/guide/collections/designfaq.html#28

Справді використовуйте здоровий глузд. Якщо у вас є щось на кшталт:

public class ScreenCoord2D{
    public int x;
    public int y;
}

Тоді немає сенсу загортати їх у геттери та сетери. Ви ніколи не збираєтесь зберігати x, y координату в цілих пікселях будь-яким іншим способом. Геттери і сетери лише уповільнить вас.

З іншого боку, з:

public class BankAccount{
    public int balance;
}

Ви можете змінити спосіб обчислення балансу в якийсь момент майбутнього. Для цього справді слід використовувати геттери та сетери.

Завжди бажано знати, чому ви застосовуєте належну практику, щоб ви знали, коли нормально виконувати правила.

Для вирішення проблем, пов’язаних із змінністю, ви можете оголосити x та y як остаточні. Наприклад:

class Data {
  public final int x;
  public final int y;
  public Data( int x, int y){
    this.x = x;
    this.y = y;
  }
}

Код виклику, який намагається записати в ці поля, отримає помилку часу компіляції "поле x оголошено остаточним; не може бути призначене".

Потім клієнтський код може мати зручність "короткої руки", яку ви описали у своїй публікації

public class DataTest {
    public DataTest() {
        Data data1 = new Data(1, 5);
        Data data2 = new Data(2, 4);
        System.out.println(f(data1));
        System.out.println(f(data2));
    }

    public int f(Data d) {
        return (3 * d.x) / d.y;
    }

    public static void main(String[] args) {
        DataTest dataTest = new DataTest();
    }
}

Не використовувати public поля

Не використовуйте publicполя, коли ви дійсно хочете обговорити внутрішню поведінку класу. Візьмемо java.io.BufferedReaderдля прикладу. Він має таке поле:

private boolean skipLF = false; // If the next character is a line feed, skip it

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

Використовуйте publicполя

Візьмемо Pointдля прикладу цей клас:

class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double getX() {
        return this.x;
    }

    public double getY() {
        return this.y;
    }

    public void setX(double x) {
        this.x = x;
    }

    public void setY(double y) {
        this.y = y;
    }
}

Це зробить обчислення відстані між двома точками дуже болісно писати.

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.getX() - a.getX(), 2) + Math.pow(b.getY() - a.getY(), 2));

Клас не має жодної поведінки, крім звичайних геттерів та сеттерів. Прийнятно використовувати загальнодоступні поля, коли клас представляє лише структуру даних, а не має і ніколи не матиме поведінки (тонкі геттери та сетери не є вважаються поведінкою). Це можна записати краще таким чином:

class Point {
    public double x;
    public double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
}

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.x - a.x, 2) + Math.pow(b.y - a.y, 2));

Чисто!

Але пам’ятайте: не тільки ваш клас повинен бути відсутнім у поведінці, але він також не повинен мати причин мати поведінку і в майбутньому.

(Саме так описується ця відповідь . Цитувати "Конвенції про коди для мови програмування Java: 10. Практики програмування" :

Одним із прикладів відповідних змінних публічних примірників є випадок, коли клас по суті є структурою даних без поведінки. Іншими словами, якщо ви використовували б structзамість класу (якщо підтримується Java struct), то доречно зробити загальні змінні екземплярів класу.

Тож офіційна документація також приймає цю практику.)

Крім того, якщо ви впевнені, що члени вищого Pointкласу повинні бути незмінні, ви можете додати finalключове слово для його виконання:

public final double x;
public final double y;

До речі, структура, яку ви наводите як приклад, вже існує в бібліотеці базового класу Java як java.awt.Point. Він має x та y як публічні поля, перевірте це на собі .

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

Re: aku, izb, John Topley ...

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

Можливо, здається розумним опускати геттерів / сетерів. Насправді це може бути нормально в деяких випадках. Справжня проблема запропонованого тут малюнка - це незмінність.

Проблема полягає в тому, що коли ви передаєте посилання на об'єкт, що містить не остаточні, загальнодоступні поля. Все, що має посилання, може змінювати ці поля. Ви більше не маєте контролю над станом цього об’єкта. (Подумайте, що було б, якщо Strings були мутаційними.)

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

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

Дивіться: " Ефективна Java " Джошуа Блоха - Пункт №13: Незмінна користь.

PS: Також пам’ятайте, що всі JVM в ці дні оптимізують метод getMethod, якщо це можливо, в результаті чого вийде лише одна інструкція з читання на місцях.

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

Як зазначали інші, у вас виникають дві проблеми, і вони насправді не виправні:

• Практично будь-який автоматизований інструмент у світі Java покладається на конвенцію про геттер / сетер. Діто для, як зазначають інші, теги jsp, конфігурація весни, інструменти затемнення тощо, тощо. Боротьба з тим, що очікують побачити ваші інструменти, - це рецепт тривалих сеансів, за допомогою яких можна шукати нестандартний спосіб ініціювання. ясна квасоля. Дійсно не вартий клопоту.
• Після того, як у вас буде елегантно кодований додаток із сотнями загальнодоступних змінних, ви, ймовірно, знайдете хоча б одну ситуацію, коли їх недостатньо - де вам абсолютно потрібна незмінність, або вам потрібно запустити якусь подію, коли змінна встановлюється, або ви хочете скинути виняток із змінної зміни, оскільки вона встановлює стан об'єкта на щось неприємне. Тоді ви заважаєте незайвим вибору між захаращуванням коду яким-небудь спеціальним методом скрізь, на який змінна безпосередньо посилається, має спеціальну форму доступу для 3 з 1000 змінних у вашій програмі.

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

Java дуже багатослівна, і це дуже спокусливо зробити. Не робіть цього.

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

Ви також не можете скористатися підтримкою сумісних класів JavaBean, що зашкодить, якщо ви вирішите, скажімо, використовувати клас на сторінці JavaServer, написану за допомогою мови виразів.

Стаття JavaWorld Чому методи Getter і Setter - це зло також може зацікавити вас при роздумах про те, коли не застосовувати методи доступу та мутаторів.

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

Немає нічого поганого в такому типі коду за умови, що автор знає, що вони є структурами (або човниками даних) замість об'єктів. Багато розробників Java не можуть визначити різницю між добре сформованим об'єктом (не лише підкласом java.lang.Object, а справжнім об’єктом у певній області) та ананасом. Ерго, вони закінчують писати структури, коли їм потрібні об'єкти і навпаки.

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

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

До речі, за твердженням e-bartek, IMO малоймовірно, що підтримка власності буде додана в Java 7.

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

Як убік, навіть якби я писав цей об’єкт як приватний внутрішній клас, я все-таки надав конструктор для спрощення коду для ініціалізації об'єкта. Необхідно мати 3 рядки коду, щоб отримати корисний об'єкт, коли це робити, просто безладно.

Дуже-дуже старе питання, але дозвольте зробити ще один короткий внесок. Java 8 представила лямбда-вирази та посилання на метод. Лямбда-вирази можуть бути простими посиланнями методів і не оголошувати "справжнє" тіло. Але ви не можете "перетворити" поле в посилання на метод. Таким чином

stream.mapToInt(SomeData1::x)

не законно, але

stream.mapToInt(SomeData2::getX)

є.

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

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

Тут я створюю програму для введення Імені та Віку 5 різних осіб та виконую сортування (за віком). Я використовував клас, який виступає як структура (як мова програмування C) і основний клас для виконання повної операції. Далі я надаю код ...

import java.io.*;

class NameList {
    String name;
    int age;
}

class StructNameAge {
    public static void main(String [] args) throws IOException {

        NameList nl[]=new NameList[5]; // Create new radix of the structure NameList into 'nl' object
        NameList temp=new NameList(); // Create a temporary object of the structure

        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));

        /* Enter data into each radix of 'nl' object */

        for(int i=0; i<5; i++) {
            nl[i]=new NameList(); // Assign the structure into each radix

            System.out.print("Name: ");
            nl[i].name=br.readLine();

            System.out.print("Age: ");
            nl[i].age=Integer.parseInt(br.readLine());

            System.out.println();
        }

        /* Perform the sort (Selection Sort Method) */

        for(int i=0; i<4; i++) {
            for(int j=i+1; j<5; j++) {
                if(nl[i].age>nl[j].age) {
                    temp=nl[i];
                    nl[i]=nl[j];
                    nl[j]=temp;
                }
            }
        }

        /* Print each radix stored in 'nl' object */

        for(int i=0; i<5; i++)
            System.out.println(nl[i].name+" ("+nl[i].age+")");
    }
}

Вищевказаний код - Помилка вільна та перевірена ... Просто скопіюйте та вставте її у свій IDE і ... Ви знаєте і що ??? :)

Ви можете створити простий клас із загальнодоступними полями та без методів у Java, але це все-таки клас і все ще обробляється синтаксично та з точки зору розподілу пам'яті так само, як клас. Немає можливості по-справжньому відтворити структури на Java.

Колись я використовую такий клас, коли мені потрібно повернути кілька значень методу. Звичайно, такий об’єкт недовговічний і з дуже обмеженою видимістю, тому він повинен бути нормальним.

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

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

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

Філософія геттера / сеттера накладає витрати на велику кількість простих випадків, коли вони не потрібні.

Будь аспектний стиль чистіший чи ні - це дещо якісний. Мені буде легко бачити лише змінні в класі та переглядати логіку окремо. Насправді, основна причина програмування, орієнтованого на Apect, полягає в тому, що багато проблем пов'язані з наскрізними, і їх розділення в тілі класу саме по собі не є ідеальним (реєстрація є прикладом - якщо ви хочете реєструвати все, що отримує Java хоче, щоб ви напишіть цілу купу гетерів і підтримуйте їх синхронізуючи, але AspectJ дозволяє однолінійний).

Проблема ІДЕ - це оселедець. Це не стільки набір тексту, скільки саме читання та візуальне забруднення, що виникає в результаті отримання / набору.

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

Я сподіваюся, що обізнаність щодо AspectJ заважає людям передчасно зупинятися на динамічних мовах.