Foro de elhacker.net

Siempre que creo una clase entidad en un programa hago lo siguiente:

public class Estudiante{
    private string nombre;
 
    public String getNombre(){
        return nombre;
    }
 
    public void setNombre(string nombre){
        this.nombre = nombre;
    }
}
 

Pero nunca me he preguntado porqué en vez de poner los atributos públicos tengo que ponerlos privados y crear métodos para acceder a las propiedades de una clase.

No se si te refieres a esto: http://www.chuidiang.com/clinux/sobrecarga/ocultacion.php (http://www.chuidiang.com/clinux/sobrecarga/ocultacion.php)

Por lo que recuerdo de clase es por el concepto de caja negra.

la realidad es que en la mayoria de casos es inutil y en lo personal yo lo hago por ser el mal menor los frameworks te obligan a usar getters y setters para que ellos puedan usar reflexion sobre tus clases y asi no estes obligado a heredar de clases abstractas o llamar clases "extrañas" y asi tener codigo "puro limpio y virginal" y que sean simples pojos lo cual es mentira por que el horrible framework te obliga a reescribir los getters y setters en un archivo gigantesco e imposible de entender creando una dependensia que ensima no es typesafe y ademas es estupida redundante y que puede ser tomada por configuracion por excepcion .¨
Pero a pesar de todo es el mal menor

es mentira de que les sirva usar getters y setters por la encapsulacion por que la realidad es que jamas usan encapsulacion y tener getters y setters es lo mismo que tener metodos publicos casi todos los programadores usan getters y setters como si fueran metodos publicos y nunca usan sus ventajas los tienen de adorno por ser "buena practica" "por que asi dise el arquitecto" "por que ese es el standar" "por que todo el mundo lo hace asi"

existe el estandar de beans pero nadie lo usa igual

la unica razón real por la que yo uso getters y setters es por los frameworks y por que si uso sus ventajas

puedes lansar exceptiones y validar los datos de entrada
puedes agregar eventos
puedes corregir errores en codigo futuro solo cambiando el geter y no en todas partes
en caso de usar herencia y te das cuenta que diseñaste mal puedes mover el getter a una clase superior
los ides te reconocen como bean y pueden ser reconocidos por la paleta

Nunca he usado un framework, así que no se mucho a lo que te refieres. Pero ahora sí me doy cuenta que con los setters se pueden validar los datos y corregir errores más facilmente.

Este es un concepto que puede resultar difícil de entender.
Yo te recomendaría que te leyeses algún libro sobre orientación a objetos para comprender por qué se hacen así las cosas tanto en java como en otros lenguajes.

Ayer mismo estuve leyendo uno que lo explica muy bien (aunque utiliza como base C++), es un libro gratuito disponible en openlibra que (creo que) se llama Programación orientada a objetos 2012 y está en castellano.

Imagínate que la cadena nombre tiene que tener más de 3 caracteres y menos de 5.
El set se encargará de comprobar si lo que le entra es válido o no.
Es la propia clase la que define sus "normas". De la otra forma la clase que lo llama podría setear lo que quisiese sin comprobar nada.

Como dice Proteus, una clase que haga uso de Estudiante no debería conocer cual es su implementación interna, ya que si así fuese estarían más acopladas. Yo siempre pienso que los atributos de una clase es ella misma la que tiene el conocimiento para manejarlos (o casi siempre) y no tiene porque haber siempre un método get/set de algún atributo, habrá casos en los que sea necesario y habrá otros casos en los que no. Pero respondiendo un poco a sapito (y así que se cree algo de polémica xD) pienso que si la mayoría de personas que han dedicado muchísima parte de su vida al desarrollo de software, estudio de patrones de diseño, y otros aspectos relacionados con el propio desarrollo recomiendan el uso de Ocultación de la información, será por algo.

Si has estudiado (o alguna vez lo haces) patrones de diseño, verás que la mayoría (o muchos de ellos) te dan consejos para que si tienes que realizar cambios sobre tu código, ese cambio afecte lo menos posible al resto del código, es decir, aumentas la reutilización, lo cual, desde mi punto de vista, es una práctica muy buena.

Saludos.