Use get and set or declare public variable?

Allowing free access to class attributes is not a doomed design, it's just different. This is usually avoided so that the class internally handles any business logic it might attach to the fields. For example:

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);
    }
}

If we then wanted to add validations to this code, the situation is complicated. Sure, in the example above you can't see it because there are only about 3 calls to Foo#listaNombres, but if it were scattered across dozens of methods the situation gets complicated. In addition, it also complicates if the definition of the attribute (name, type, etc) were changed, due to all the changes that would be made. An additional problem is that when getting the list of Foo#listaNombreswe don't want to pass the list directly, instead we want a copy of it. We could make the copy at each location of foo.listaNombresbut that leads to duplicate code (well, multiplied rather than duplicated).

getThe use of the and set(preferably public) methods is according to the JavaBean specification :

7Properties

Properties are discrete, named attributes of a Java Bean that can affect its appearance or its behavior. For example, a GUI button might have a property named “Label” that represents the text displayed in the button.

Properties show up in a number of ways:

Properties may be exposed in scripting environments as though they were fields of objects. So in a Javascript environment I might do “b.Label = foo” to set the value of a property. Properties can be accessed programmatically by other components calling their getter and setter methods (see Section 7.1 below). (...)

7.1 Accessor methods

Properties are always accessed via method calls on their owning object. For readable properties there will be a getter method to read the property value. For writable properties there will be a setter method to allow the property value to be updated.

Translated:

7 Properties

Properties are discrete, named attributes of a Java Bean that can affect its appearance or behavior. For example, a GUI button might have a property called "Label" that represents the text that is displayed on the button.

Properties are displayed in several ways:

Properties can be exposed in scripting environments as if they were object fields. So, in a JavaScript environment you could do "b.Label = foo" to assign the value of a property. Properties can be accessed programmatically by other components that call their get and set methods (see section 7.1 below). (...)

7.1 Access methods

Properties are always accessed through method calls on the object that owns them. For readable properties, there will be a get method to read the value of the property. For writable properties, there will be a set method that allows the property value to be updated.

This means that the get and set methods allow access to the properties (attributes) of a class. Many frameworks benefit from this definition. To name a few:

• Spring, CDI, Guice (IoC, dependency injection)
• Hibernate, MyBatis (data access)
• XStream, Jackson, Gson (conversion between objects and JSON, XML and other formats)
• Spring MVC, JSF, Expression Language, JSTL, etc (web MVC)
• JavaFX (desktop GUI)
• Metro, Apache CXF, Apache Axis (implementing/consuming Web services)
• Etc. Or rather: any framework that works with objects using reflection, which is normally based on using classes with default constructors and access to attributes through get and set methods.

Placing an example from Spring with XML configuration:

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

The Java class associated with this bean:

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 example for field association using Expression Language:

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

The associated Java class:

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;
    }
}

Also, the "nice" (?) thing about using these methods is that you can add business logic to them to avoid direct contact with the objects you interact with. From the previous case that we indicated that we want to get a copy of the list instead of getting the list directly, we could add such logic in the get method:

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);
    }
}

If generating the code for these methods seems too much effort, you can use lombok which offers facilities to add these methods via annotations in your code, among other benefits.

Adapted from Private List with Getter/Setter vs Public List

You've just captured one of the most common questions from developers, "Do I use properties or do I access class attributes directly?" In the other answers you have good examples, I can put a simple one:

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

Versus

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);

The second segment uses properties to control the value of the attribute, but although it makes use of one of the basic principles of object-oriented programming, it doesn't make sense if we don't require (or will require in the future) to control the inputs/outputs of that attribute. .

You do not need to apply all the theoretical concepts that you know at first instance, many of them you will have to apply as your application matures or scales, control needs increase, but the business logic will tell you whether or not you should encapsulate the attributes of your application. class. Sometimes too much encapsulation ends up creating code monsters like:

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

When it can be more readable as:

WindowManager.instance.topWindow.initialPoint.x;

But as I said before, it will depend on the business logic of your application which one to use.

Yes, there are good reasons to use them, although they should not be considered universally necessary. If you declare a variable (or field ) public, you allow direct access to its content without any control measures. In many cases this does not have to be a problem, but with a growing system it can be.

Implementing methods to access the variable gives you a possibility at any time to add code that controls access to the variable without having to change the interface of your class. I give you an example.

Let's consider this class:

public class Persona{

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

compared to the version with getandset

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;
    }

}

At some point we realize that we have to guarantee that at no time name or surname remain null.

With first class that's basically impossible, persona.nombre = null;it's nothing we could ban. However in the other version there is a super easy way:

    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;
    }

and we get an exception if someone tries to set null.

A more practical example would be that you have to implement a timestamp to back up the update data. Without getters and setters we would have to make sure to check all the code in which the fields could be modified. The practice of using default setters allows us an easier path:

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);
    }

Thus it was possible to implement this functionality only in the model in a class.

On the contrary, a paradigm in which getters and setters are completely redundant are immutable VO s ( value objects, value objects ). An example:

public class PersonaVO{

    public final String nombre;
    public final String apellido;

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

In this case getters or setters would be completely meaningless.

As you can see, yes, there are reasons, but it all depends on the design and context.

The Gets are the outputs and the Sets are the inputs of the class. It is considered a good practice to implement them mainly for security reasons since we maximize encapsulation.

We isolate the actual representation of the data and would only have access to the behavior.