Структурировать подобные объекты в Java

Я не вижу вреда, если вы знаете, что это всегда будет простая структура и что вы никогда не захотите привязать к ней поведение.

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

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

Статья JavaWorld Почему методы геттера и сеттера - зло также может быть интересна вам, когда вы подумаете о том, когда не следует реализовывать методы доступа и мутатора.

Если вы пишете небольшое решение и хотите минимизировать объем используемого кода, способ Java может быть неправильным - я думаю, это всегда зависит от вас и проблемы, которую вы пытаетесь решить.

Это часто обсуждаемая тема. Недостаток создания общедоступных полей в объектах заключается в том, что вы не можете управлять значениями, которые им задаются. В групповых проектах, где много программистов используют один и тот же код, важно избегать побочных эффектов. Кроме того, иногда лучше вернуть копию объекта поля или как-то его преобразовать и т. д. Вы можете смоделировать такие методы в своих тестах. Если вы создадите новый класс, вы можете увидеть не все возможные действия. Это похоже на защитное программирование - когда-нибудь геттеры и сеттеры могут оказаться полезными, и их создание / использование не требует больших затрат. Так что иногда они полезны.

На практике у большинства полей есть простые геттеры и сеттеры. Возможное решение могло бы выглядеть так:

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

Обновление: маловероятно, что поддержка свойств будет добавлена ​​в Java 7 или, возможно, когда-либо. Другие языки JVM, такие как Groovy, Scala и т. д., Теперь поддерживают эту функцию. - Алекс Миллер

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

Кстати, структура, которую вы даете в качестве примера, уже существует в библиотеке базовых классов Java как java.awt.Point. Он имеет x и y как общедоступные поля, Убедитесь сами.

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

Правильно руководствуйтесь здравым смыслом. Если у вас есть что-то вроде:

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

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

С другой стороны, с:

public class BankAccount{
    public int balance;
}

Возможно, вы захотите изменить способ расчета баланса в какой-то момент в будущем. Это действительно должно использовать геттеры и сеттеры.

Всегда предпочтительно знать Почему, что вы применяете хорошую практику, чтобы знать, когда можно нарушить правила.

Re: аку, изб, Джон Топли ...

Остерегайтесь проблем с изменчивостью ...

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

Проблема заключается в том, что вы передаете ссылку на объект, содержащую неокончательные общедоступные поля. Все, что связано с этой ссылкой, может изменять эти поля. У вас больше нет контроля над состоянием этого объекта. (Подумайте, что бы произошло, если бы строки были изменяемыми.)

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

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

См .: «Эффективная Java» Джошуа Блоха - Пункт № 13: Поддерживайте неизменность.

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

Чтобы решить проблемы изменчивости, вы можете объявить 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();
    }
}

Проблема с использованием доступа к общедоступным полям такая же, как и при использовании нового вместо фабричного метода - если вы передумаете позже, все существующие вызывающие объекты будут сломаны. Итак, с точки зрения эволюции API, обычно рекомендуется укусить пулю и использовать геттеры / сеттеры.

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

Между прочим, по утверждению e-bartek, весьма маловероятно, что, IMO, поддержка свойств будет добавлена ​​в Java 7.

Я часто использую этот шаблон при создании частных внутренних классов, чтобы упростить свой код, но я бы не рекомендовал раскрывать такие объекты в общедоступном API. В общем, чем чаще вы можете делать объекты в своем общедоступном API неизменяемыми, тем лучше, и невозможно создать свой «структурно-подобный» объект неизменяемым образом.

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

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

Иногда я использую такой класс, когда мне нужно вернуть несколько значений из метода. Конечно, такой объект недолговечный и с очень ограниченной видимостью, так что все должно быть в порядке.

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

Как уже отмечалось выше, есть 2 проблемы, с которыми вы сталкиваетесь, и на самом деле они не решаемы:

• Практически любой автоматизированный инструмент в мире Java полагается на соглашение о получении и установке. То же самое, как отмечали другие, теги jsp, конфигурация пружины, инструменты eclipse и т. д. И т. Д. Борьба с тем, что ожидают увидеть ваши инструменты, - это рецепт для долгих сеансов, проходящих через Google, пытаясь найти этот нестандартный способ запуска Spring beans. На самом деле не стоит беспокоиться.
• Если у вас есть элегантно закодированное приложение с сотнями общедоступных переменных, вы, вероятно, найдете по крайней мере одну ситуацию, в которой их недостаточно - когда вам абсолютно необходима неизменяемость, или вам нужно вызвать какое-то событие, когда переменная будет установлена, или вы хотите выбросить исключение при изменении переменной, потому что оно устанавливает состояние объекта на что-то неприятное. Затем вы застряли перед незавидным выбором между загромождением вашего кода каким-либо специальным методом везде, где переменная напрямую упоминается, имея некоторую специальную форму доступа для 3 из 1000 переменных в вашем приложении.

И это в лучшем случае полностью работать в автономном частном проекте. Как только вы экспортируете все это в общедоступную библиотеку, эти проблемы станут еще больше.

Java очень многословен, и это очень соблазнительно. Не делай этого.

В этом типе кода нет ничего плохого, при условии, что автор знает представляет собой структуры (или шаттлы данных), а не объекты. Многие разработчики Java не могут отличить хорошо сформированный объект (не только подкласс java.lang.Object, но и объект истинный в определенном домене) и ананас. Следовательно, они в конечном итоге пишут структуры, когда им нужны объекты, и наоборот.

Как и в большинстве случаев, есть общее правило, а затем есть определенные обстоятельства. Если вы создаете закрытое захваченное приложение, чтобы знать, как будет использоваться данный объект, вы можете проявить больше свободы в пользу видимости и / или эффективности. Если вы разрабатываете класс, который будет публично использоваться другими людьми, не зависящими от вас, тогда склоняйтесь к модели получателя / установщика. Как и во всем, просто руководствуйтесь здравым смыслом. Часто бывает нормально провести начальный раунд с пабликами, а потом поменять их на геттеры / сеттеры.

Похоже, что многие люди, занимающиеся Java, не знакомы с Руководством по кодированию Sun Java. которые говорят, что вполне уместно использовать общедоступную переменную экземпляра, когда класс по сути, «структура», если Java поддерживает «структуру» (когда нет поведения).

Люди склонны думать, что геттеры и сеттеры - это способ 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

Аспектно-ориентированное программирование позволяет вам перехватывать назначения или выборки и присоединять к ним логику перехвата, что, как я предлагаю, является правильным способом решения проблемы. (Вопрос о том, должны ли они быть общедоступными, защищенными или защищенными пакетами, ортогонален.)

Таким образом, вы начинаете с неперехваченных полей с правильным квалификатором доступа. По мере роста требований к программе вы присоединяете логику, возможно, для проверки, создания копии возвращаемого объекта и т. д.

Философия геттера / сеттера требует затрат в большом количестве простых случаев, когда они не нужны.

Является ли аспектный стиль более чистым или нет, в некоторой степени качественным. Мне было бы легко видеть только переменные в классе и отдельно рассматривать логику. Фактически, смысл существования Apect-ориентированного программирования заключается в том, что многие проблемы являются сквозными, и разделение их в теле самого класса не идеально (например, ведение журнала - если вы хотите регистрировать все, что Java хочет, чтобы вы напишите целую кучу геттеров и синхронизируйте их, но AspectJ позволяет вам однострочно).

Проблема IDE - отвлекающий маневр. Это не столько набор текста, сколько чтение и визуальное загрязнение, возникающее из-за get / sets.

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

Я надеюсь, что знание AspectJ предотвратит преждевременное использование динамических языков.

Здесь я создаю программу для ввода имени и возраста 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 8 появились лямбда-выражения и ссылки на методы. Лямбда-выражения могут быть простыми ссылками на методы и не объявлять «истинное» тело. Но вы не можете «преобразовать» поле в ссылку на метод. Таким образом

stream.mapToInt(SomeData1::x)

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

stream.mapToInt(SomeData2::getX)

является.

Не используйте поля 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. Практики программирования»:

One example of appropriate public instance variables is the case where the class is essentially a data structure, with no behavior. In other words, if you would have used a struct instead of a class (if Java supported struct), then it's appropriate to make the class's instance variables public.

Таким образом, официальная документация также принимает эту практику.)

Кроме того, если вы абсолютно уверены, что члены вышеуказанного класса Point должны быть неизменными, вы можете добавить ключевое слово final, чтобы обеспечить его соблюдение:

public final double x;
public final double y;