Encapsulamiento

Podrias extender un poco el post si mencionas algo de colecciones... el ejemplo típico es que tienes un objeto con una colección interna mutable, para la cual quieres poner un getter; el getter debería devolver una copia inmutable de la colección, porque si devuelves directamente la colección, alguien la puede modificar por fuera.

Ahí hay una ventaja clara del encapsulamiento... otra es validación de datos:

Mas fácil que los conceptos de la uni... pero ya que mencionas los modificadores de acceso, es cierto que es una mala práctica de programación el no poner el modificador de acceso a la variable?? y ya mencionado esto, habrá un post o alguien conoce donde puedo saber más sobre las buenas prácticas de programación.

@AlexSnake
Yeap, es mala práctica, sobre todo si se hace sin una razón clara.

Lo puse ahí en el post, pero como lo veía tan ... mmhh simple ya no quize profundizar en el tema:

"Lo más recomendado es tener el modificador de acceso más restrictivo para los atributos, de forma que además de encapsulados queden ocultos evitando que alguien modifique por error los valores. En Java el modificador de acceso para hacer esto es private"

Por ejemplo una buena razón para hacer esto es porque estas escribiendo un ejemplo y no poner modificadores de acceso me hace escribir menos ( yo lo hago todo el tiempo acá en JavaMexico ) Pero en código real ( usado por alguien más ) no haría eso.

También es mala práctica poner getters / setters a todo nomás porque sí.

Es decir el criterio de que algo está mal o no es si lo haces nomás porque así lo viste, pero en realidad no entiendes sus implicaciones.

Por ejemplo en común en los JSP's o incluso en archivos Java tener en un import todo:

Nomás porque "así es como compila". Si tienes una razón contundente y razonada puedes hasta hacer que todos los atributos sean públicos, pero si no la tienes lo mejor es hacer que todos los atributos ( e incluso los métodos ) sean privados hasta que esa razón aparezca. Me entiendes?

@ezamudio Si es muy importante ese tema, sobre todo en el aspecto de los objetos mutables.

Por ejemplo, si tuvieramos una clase mutable que fuera ... ... mmmhhh Telefono:

Y si la persona tuviera un telefono, hay un gran riesgo de exponer ese atributo telefono porque al ser mutable puede modificar nuestro propio estádo:

Imaginemos que un usuario solo puede tener un telefono con terminacion 03 y si no lo tiene debe de lanzar un error:

Ok, una persona tiene un telefono, y es declarado como una variable final ( o sea que no se le puede asignar un nuevo telefono ) y tampoco hay setter para el Telefono, así que se podría tener la falsa creencia que este valor está seguro y que podemos confiar en él.

Se hace una validación para ver que el telefono efectivamente termine en 03 ( es una regla que me acabo de inventar )

Parece que todo esta bien encapsulado y demás , el problema con este código es que como la clase   es mutable, ya no se puede confiar en ella. Supongamos que el código del método   confía en que ya el telefono es válido para marcar, si no termina en 03... no sé le cobran el triple o algo.

Que pasaría si alguién le pide el telefono a la persona:

Pues que ese código ahora puede hacer lo que quiera con el telefono... por ejemplo cambiarle el número

O bien lo pone en nulo
 

La solución incorrecta es agregar validaciones en el método marcar!... Esto se ha vuelto tan común que ya nadie piensa en la razón de esto y culpan al lenguaje! "Java es horrible porque tiene nulos y puede lanzar NullPointerException" y muchas veces se termina haciendo cosas como:

Esta es la forma más común y erronea de solucionar el problema. No deberíamos de andar revisando nuestras reglas todo el tiempo. Acá parece poca cosa, pero cuando se tiene un sistema con 10 - 20 métodos y todos andan revisando siempre la misma cosa, solo porque ya no confian en sí mismos ( en sus atributos internos y privados!!! ) entonces hay algo mal. Luego este código se vuelve más y más difícil de leer y mantener.

La solución no es agregar duplicar las validaciones, sino regresar el control a donde se necesita:

Así es, crear una copia. Y así puedo seguir confiando en mi teléfono, porque aunque por fuera se le cambien los valores:

Mi método   sigue funcionando bien. No tengo que repetir las validaciones ni nada. Sigo confiando en mis atributos.

Pero la queja está en que estoy teniendo que crear otro objeto ( ahora tengo 2 objetos con la misma información ) y eso consume más memoria, debería de ser innecesaario etc.

Pues la culpa la tiene el objeto mutable telefono y es necesario hacer esto para evitar que falle.

Una alternativa todavía mejor aún hubiera sido tener la clase   como inmutable. De esa forma no se necesita crear una copia, porque como es inmutable pueees, no cambia el valor, una vez validada podemos seguir confiando en ella, no hay que crear nuevos datos ni nada.

Y listo, una vez creado el telefono no cambiará su número y la clase persona puede confiar en él sin tener que hacer copias defensivas.
 

Un efecto similar se puede presentar con los threads y la sincronización. Un objeto no mutable no necesita sincronización y el código es más simple, pero esta entrada ya es suficientemente larga.

@OscarRyz

Buena explicación sobre polimorfismo y encapsulación.

Se supone que las validaciones deberian hacerse en los setters, y si hay una excepcion pues controlarla, mencionando que hay un error en la informacion, asi el usuario la deberia de solucionar o al menos saber que existe ese error.

Ademas los valores nulos se deberian de utilizar.

Gracias Oscar por la explicacion ahora me queda mas claro y sobre lo que mencionas de la mutabilidad, entonces se puede resumir que solo se trata de modificar el valor de la variable mediante un set.

Solo queria aportar como se veria el codigo de @ezamudio en java 7
 

Los avances en Java 7 la verdad se quedaron muy cortos. Ese mismo código en Groovy y Scala sigue siendo más corto:

pueees...

O sea que ryz no tiene keyword para definir variables? En lo personal eso nunca me ha gustado, hace el software más difícil de depurar; cuando ves entre un montón de código una línea que dice  , están declarando la variable ahí, o sólo actualizaron su valor y ya venía desde antes? Y si estoy manteniendo código, cómo sé que al insertar una variable nueva, no estoy sobreescribiendo una variable existente, cuyo valor se necesita leer más abajo?

En los lenguajes que vemos aquí regularmente, declaras la variable poniéndole el tipo, o val, o var, o def; el compilador se queja si ya existe una variable con el mismo nombre en ese mismo contexto, o te avisa si estás ocultando una variable de un contexto más externo (si el lenguaje lo permite).

Eso es algo que no me gustó mucho de Erlang; la primera vez que dices   el runtime dice "ok, a vale 5". La siguiente vez que escribes   obtienes  ... WTF? ah pues es que como todo es inmutable en Erlang, las comparaciones las haces con un solo = y como   ya tiene un valor asignado, estás comparando si a vale 5. Si pones   obtienes  . Prefiero el comportamiento y sintaxis de Scala, donde tienes que poner   y si luego se te ocurre hacer   o a=2 el compilador se queja de que quieres modificar un valor inmutable.

por cierto, esa   en ryz, es mutable? inmutable? bueno no la lista en sí (un ArrayList es mutable, no hay de otra), pero se puede asignar un ArrayList distinto a esa variable después, o ya no?

O sea que ryz no tiene keyword para definir variables?

Exacto

En lo personal eso nunca me ha gustado...

Si, hay que tener cuidado, lo mismo pasa con JavaScript, pero ahí si se puede poner  

Para asegurarse de no tomar una existente la "mejor práctica" es declarar el tipo de dato y listo!

Otra opción que se consideró fue como en Python forzar a:   o como en Ruby   , pero me parece mejor esta opción.

Eso es algo que no me gustó mucho de Erlang...

Ajap... es un riesgo, como decía las opciones para quién se quiere asegurar de que esto no suceda con declaración de tipo y/o usar  .

por cierto, esa lista en ryz, es mutable? inmutable?

Ahora mismo ( 22 sept 2011 ) es "non-final", pero solo porque no he encontrado un simbolo que represente "non-final". Cuando lo encuentre por omisión todos los atributos serán "leaf" ( final en Java ) y habrá que hacerlos non-final explicitamente.

El candidato más fuerte es el símbolo:   ( admiración ) que significa: "Advertencia, el uso de este atributo tiene efectos secundarios" sin embargo tiene el gran inconveniente de confundirse con la negación en Java.

Otra opción es tener 1 palabra resevada "var" ( por variable )

Cuando haya definido esa parte entonces todos los atributos serán "leaf" o "final" por omisión. Pero hasta entonces, no tengo forma de poner variables "finals".

Alguien sugiere algo?