Использовать get и set или объявить общедоступную переменную?

Предоставление свободного доступа к атрибутам класса — это не обреченный проект, он просто другой. Обычно этого избегают, чтобы класс внутренне обрабатывал любую бизнес-логику, которую он может прикрепить к полям. Например:

public class Foo {
    public List<String> listaNombres;
    public Foo() {
        listaNombres = new ArrayList<>(Arrays.asList("Friky", "Luiggi"));
    }
}

public class Otro {
    public List<String> listaNombresOtro;
    public void obtieneDeFoo(Foo foo) {
        listaNombresOtro = foo.listaNombres;
    }

    public static void main(String[] args) {
        Foo foo = new Foo();
        System.out.println(foo.listaNombres);
        Otro otro = new Otro();
        otro.obtieneDeFoo(foo);
        otro.listaNombresOtro.set(0, "Cambio");
        System.out.println(foo.listaNombres);
        System.out.println(otro.listaNombresOtro);
    }
}

Если бы мы потом захотели добавить валидации в этот код, ситуация усложнилась бы. Конечно, в приведенном выше примере вы его не видите, потому что вызовов всего около 3 Foo#listaNombres, но если он будет разбросан по десяткам методов, ситуация усложнится. Кроме того, это также усложняет, если определение атрибута (имя, тип и т. д.) было изменено из-за всех изменений, которые будут сделаны. Дополнительная проблема заключается в том, что при получении списка Foo#listaNombresмы не хотим передавать список напрямую, вместо этого нам нужна его копия. Мы могли бы сделать копию в каждом месте, foo.listaNombresно это приведет к дублированию кода (точнее, умножению, а не дублированию).

Использование методов getand set(предпочтительно общедоступных) соответствует спецификации JavaBean :

7Свойства

Свойства — это дискретные именованные атрибуты Java Bean, которые могут влиять на его внешний вид или поведение. Например, кнопка графического интерфейса может иметь свойство с именем «Ярлык», которое представляет текст, отображаемый на кнопке.

Свойства проявляются несколькими способами:

Свойства могут отображаться в средах сценариев, как если бы они были полями объектов. Таким образом, в среде Javascript я мог бы использовать «b.Label = foo», чтобы установить значение свойства. Доступ к свойствам может осуществляться программно другими компонентами, вызывающими их методы получения и установки (см. Раздел 7.1 ниже). (...)

7.1 Методы доступа

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

Переведено:

7 свойств

Свойства — это дискретные именованные атрибуты Java Bean, которые могут влиять на его внешний вид или поведение. Например, кнопка графического интерфейса может иметь свойство «Метка», представляющее текст, отображаемый на кнопке.

Свойства отображаются несколькими способами:

Свойства могут быть представлены в средах сценариев, как если бы они были полями объекта. Итак, в среде JavaScript вы можете использовать «b.Label = foo», чтобы присвоить значение свойства. Доступ к свойствам может осуществляться программно другими компонентами, вызывающими их методы get и set (см. раздел 7.1 ниже). (...)

7.1 Методы доступа

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

Это означает, что методы get и set позволяют получить доступ к свойствам (атрибутам) класса. Многие фреймворки выигрывают от этого определения. Назвать несколько:

• Spring, CDI, Guice (IoC, внедрение зависимостей)
• Hibernate, MyBatis (доступ к данным)
• XStream, Jackson, Gson (преобразование между объектами и форматами JSON, XML и др.)
• Spring MVC, JSF, язык выражений, JSTL и т. д. (веб-MVC)
• JavaFX (графический интерфейс рабочего стола)
• Metro, Apache CXF, Apache Axis (внедрение/использование веб-сервисов)
• И т.д. А точнее: любой фреймворк, который работает с объектами с помощью отражения, которое обычно основано на использовании классов с конструкторами по умолчанию и доступе к атрибутам через методы get и set.

Размещение примера из Spring с конфигурацией XML:

<bean id="fooBean" class="paquete.de.mis.clases.Foo">
    <property name="listaNombres">
        <list>
            <value>Friky</value>
            <value>Luiggi</value>
        </list>
    </property>
</bean>

Класс Java, связанный с этим компонентом:

package paquete.de.mis.clases;

public class Foo {
    private List<String> listaNombres;
    public List<String> getListaNombres() {
        return this.listaNombres;
    }
    //permite a Spring asignar el valor de la lista mediante reflexión
    public void setListaNombres(List<String> listaNombres) {
        this.listaNombres = listaNombres;
    }
}

Пример JSF для ассоциации полей с использованием языка выражений:

<!-- permite a JSF llamar al getter mediante reflexión -->
<h:dataTable value="#{foo.listaNombres}" var="nombre">
    <h:column>
        #{nombre}
    </h:column>
</h:dataTable>

Связанный класс Java:

package paquete.de.mis.managedbeans;

@ManagedBean
@ViewScoped
public class Foo {
    private List<String> listaNombres;
    @PostConstruct
    public void init() {
        listaNombres = new List<>();
        listaNombres.add("Friky");
        listaNombres.add("Luiggi");
    }
    public List<String> getListaNombres() {
        return this.listaNombres;
    }
    public void setListaNombres(List<String> listaNombres) {
        this.listaNombres = listaNombres;
    }
}

Кроме того, "приятная" (?) вещь в использовании этих методов заключается в том, что вы можете добавить к ним бизнес-логику, чтобы избежать прямого контакта с объектами, с которыми вы взаимодействуете. Из предыдущего случая, когда мы указали, что хотим получить копию списка, а не получать список напрямую, мы могли бы добавить такую ​​логику в методе get:

public class Foo {
    private List<String> listaNombres;
    public List<String> getListaNombres() {
        //en lugar de devolver la lista directamente
        //devolvemos una nueva lista con los elementos
        //de mi lista actual
        return new ArrayList<>(this.listaNombres);
    }
}

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

Адаптировано из частного списка с Getter/Setter vs Public List

Вы только что ответили на один из самых распространенных вопросов разработчиков: «Использую ли я свойства или напрямую обращаюсь к атрибутам класса?» В других ответах у вас есть хорошие примеры, я могу поставить простой:

public class Point {
    int x = 0;
}
Point point = new Point();
point.x = 1;

Против

public class Point {
    int x = 0;

    public int getX() {
        return this.x;
    }
    public void setX(int x) {
        this.x = x;
    }
}
Point point = new Point();
point.setX(1);

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

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

WindowManager.getInstance().getTopWindow().getInitialPoint().getX()

Когда это может быть более читабельно, как:

WindowManager.instance.topWindow.initialPoint.x;

Но, как я уже говорил, какой из них использовать, будет зависеть от бизнес-логики вашего приложения.

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

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

Рассмотрим этот класс:

public class Persona{

    public String nombre="";
    public String apellido="";
}

по сравнению с версией с getиset

public class Persona {

    private String nombre="";
    private String apellido="";
    public String getNombre() {
        return nombre;
    }
    public void setNombre(String nombre) {
        this.nombre = nombre;
    }
    public String getApellido() {
        return apellido;
    }
    public void setApellido(String apellido) {
        this.apellido = apellido;
    }

}

В какой-то момент мы понимаем, что должны гарантировать, что никогда не останется ни имени, ни фамилии null.

С первым классом это практически невозможно, persona.nombre = null;мы ничего не можем запретить. Однако в другой версии есть очень простой способ:

    public void setNombre(String nombre) {
        if (nombre!=null) throw new IllegalArgumentException("null no permitido");
        this.nombre = nombre;
    }

    public void setApellido(String apellido) {
        if (apellido!=null) throw new IllegalArgumentException("null no permitido");
        this.apellido = apellido;
    }

и мы получаем исключение, если кто-то пытается установить значение null.

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

public class Persona {

    private String nombre="";
    private String apellido="";
    private long timestamp=new Date().getTime();

    public String getNombre() {
        return nombre;
    }

    public void setNombre(String nombre) {
        if (!this.nombre.equals(nombre)) timestamp = new Date().getTime();
        this.nombre = nombre;
    }

    public String getApellido() {
        return apellido;
    }

    public void setApellido(String apellido) {
        if (!this.nombre.equals(nombre)) timestamp = new Date().getTime();
        this.apellido = apellido;
    }

    public Date getActualizado(){
        return new Date(timestamp);
    }

Таким образом реализовать эту функциональность можно было только в модели в классе.

Напротив, парадигма, в которой геттеры и сеттеры полностью избыточны, — это неизменяемые ВО (объекты-значения, объекты-значения). Пример:

public class PersonaVO{

    public final String nombre;
    public final String apellido;

    public PersonaVO(String nombre, String apellido){
        this.nombre=nombre;
        this.apellido=apellido;
    }
}

В этом случае геттеры или сеттеры были бы совершенно бессмысленными.

Как видите, да, причины есть, но все зависит от дизайна и контекста.

Gets — это выходы, а Sets — это входы класса. Считается хорошей практикой реализовывать их в основном из соображений безопасности , поскольку мы максимизируем инкапсуляцию.

Мы изолируем фактическое представление данных и будем иметь доступ только к поведению.