ENCAPSULAMIENTO 1.

La razn de ser del encapsulamiento es principalmente limitar o denegar el acceso directo a la variable u objeto, si utilizas un mtodo para acceder a ella podrs dentro del mtodo realizar ciertas validaciones o establecer un comportamiento en particular cuando se modifica o se intenta modificar su valor. Por ejemplo, digamos que tienes una variable que te almacenar la edad de una persona, si no utilizas el encapsulamiento cualquiera que tenga acceso a esa variable podr establecer cualquier valor, incluyendo nmeros negativos an cuando la edad no puede ser representada de esa manera, en caso de que utilices un mtodo pblico para modificar el valor de esa variable privada (encapsulamiento) podrs limitar el rango de valores que puede tener y por lo tanto, garantizars que siempre tendr un valor real. Espero haberme explicado un poco ms. Saludox.
2. Imaginemos que se crea una clase, una docena de programadores tienen acceso a dicha clase y la utilizan a discrecin, posteriormente dicha clase comienza a comportarse de una manera inesperada debido a que los valores que algunas variables han tomado no fueron anticipados y todo comienza a desmoronarse. Para corregir el problema se crea una versin ms nueva de dicha clase y listo. 3. 4. Bueno, a esto le llamamos flexibilidad y capacidad de mantenimiento, ambas son caractersticas y beneficios de la programacin Orientada a Objetos (OO) pero para que una clase pueda cumplir dichas funciones los programadores debemos de hacer algo. Imaginemos que creamos una clase con variables de instancia pblicas a las cuales podemos acceder sin problemas desde fuera de la misma clase... 5. public class MiClase{ public int tipo; }

class AccesoDirecto{ public static void main(String[] args){ MiClase mc = new MiClase();

mc.tipo = -5; //1 } } 6. Analizando el cdigo anterior podemos darnos cuenta de que las variables enteras tipo y clase son pblicas y pueden ser accedidas directamente a travs de una instancia de

la clase MiClase, esto compila sin ningn problema, digamos que es 'legal', sin embargo, qu pasa si ingresamos un valor que no se supone debe de tener una variable (en este caso el -5 que le asignamos a tipo)?, simplemente no hay nada que nos detenga para hacerlo. La nica manera de proteger el cdigo es escribiendo un mtodo que nos permita regular los valores que cada variable puede tener y escondiendo las variables para que no se pueda acceder a ellas de manera directa, esto es el principio bsico de encapsulamiento. 7. Si se desea flexibilidad, buen mantenimiento y extensibilidad, nuestro diseo en el cdigo debe de incluir encapsulamiento, para ello debemos de hacer lo siguiente:

* Mantener las variables de instancia protegidas (puede ser con un modificador de acceso, p.ej., private) * Hacer mtodos de acceso pblicos para forzar al acceso a las variables por medio de dichos mtodos en lugar de acceder directamente. * Utilizar las convenciones de cdigo para los nombres de los mtodos, p. ej., set y get.

El ejemplo anterior modificado para un buen encapsulamiento quedara as:

public class MiClase{ private int tipo;

public void setTipo(int t){ tipo = t; }

public int getTipo(){ return tipo; } }

class AccesoIndirecto{

public static void main(String[] args){ MiClase mc = new MiClase(); mc.setTipo(5);

System.out.println("El tipo es:" + mc.getTipo()); }

} 8. Si nos fijamos un poquito, en el mtodo setTipo() no existen validaciones para prevenir que un valor no vlido sea asignado a la variable, sin embargo, el proveer de un mtodo de este tipo desde el diseo inicial de la aplicacin nos permite posteriormente modificar el comportamiento de la misma sin afectar los mtodos utilizados, tal vez en un futuro se desee que dicha variable solamente pueda tener uno entre un rango de valores y se podrn aplicar posteriormente los cambios sin que haya repercusiones negativas.

Control de Acceso
Anterior | Siguiente En C++ el control de acceso es menos complicado que en Java. Cualquier miembro individual de una clase en C++, puede ser designado como: private, public o protected. Un miembro private solamente puede ser accedido por otros miembros de la propia clase; no puede ser accedido por miembros de una clase heredada. Es la designacin ms restrictiva de todas. Un miembro designado como public puede ser accedido desde cualquier cdigo dentro del mbito de un objeto instanciado a partir de la clase. Es la designacin menos restrictiva. La designacin de protected entra en juego solamente cuando se ve involucrada la herencia. Un miembro designado como protected aparece como public para los miembros de clases derivadas de la clase y aparece como private para todas las dems. En C++ hay un segundo nivel de control de acceso con las mismas palabras reservadas, que no tiene analoga en Java, y que se aplica a nivel de la herencia de una clase desde otra clase. Tambin en C++, hay un aspecto adicional que son las funciones friend de una clase. Estas funciones tienen acceso a todos los miembros privados y protegidos de esa clase. Esta funcin puede ser una funcin miembro de otra clase o simplemente una funcin aislada (que no est soportada en Java). Java no tiene nada semejante a las funciones friend de C++. El control de acceso se aplica siempre a nivel de clase, no a nivel de objeto. Es decir, los mtodos de instancia de un objeto de una clase determinada tienen acceso directo a los miembros privados de cualquier otro objeto de la misma clase. En Java, el control de acceso se complica un poco por la inclusin de la nocin de package (paquete). Java implementa los mismos tres especificadores de acceso que C++ (aunque no necesariamente con el mismo significado) y, adems, implementa ese cuarto especificador si no se ha indicado ninguno de los otros tres, que es el definido como package, default o friendly. Por lo tanto, cuando se crea una nueva clase en Java, se puede especificar el nivel de acceso que se quiere para las variables de instancia y los mtodos definidos en la clase: private, protected, public y package.

La tabla siguiente muestra el nivel de acceso que est permitido a cada uno de los especificadores:
Nivel de Acceso clase subclase paquete todos

Private Protected Public Package

X X X X X* X X X X X

Si se profundiza en el significado de la tabla, se puede observar que la columna clase indica que todos los mtodos de una clase tienen acceso a todos los otros miembros de la misma clase, independientemente del nivel de acceso especificado. La columna subclase se aplica a todas las clases heredadas de la clase, independientemente del paquete en que residan. Los miembros de una subclase tienen acceso a todos los miembros de la superclase que se hayan designado como public. El asterisco (*) en la interseccin subclaseprotected quiere decir que si una clase es a la vez subclase y est en el mismo paquete que la clase con un miembro protected, entonces la clase tiene acceso a es miembro protegido. En general, si la subclase no se encuentra en el mismo paquete que la superclase, no tiene acceso a los miembros protegidos de la superclase. Los miembros de una subclase no tienen acceso a los miembros de la superclase catalogados como private o package, excepto a los miembros de una subclase del mismo paquete, que tienen acceso a los miembros de la superclase designados como package. La columna paquete indica que las clases del mismo paquete tienen acceso a los miembros de una clase, independientemente de su rbol de herencia. La tabla indica que todos los miembros protected, public y package de una clase pueden ser accedidos por otra clase que se encuentre en el mismo paquete. Esto puede asemejarse un poco a la designacin de funciones friend en C++, salvando las diferencias, que no son pocas. En C++, se puede calificar un mtodo en una clase diferente como friend de una clase determinada y ese status de friend no se extiende a ningn otro mtodo de la clase, es decir, una persona de otra familia puede ser tu amigo, pero no por eso tienen que ser tus amigos el resto de los miembros de la familia de tu amigo. En Java, colocando dos o ms clases en el mismo paquete se hace que la relacin friend, de amistad, se extienda a todos los mtodos de las clases, es decir, si eres amigo de uno de los miembros de una familia, sers amigo automticamente de todos y cada uno de los componentes de esa familia. La columna todos indica que los privilegios de acceso para mtodos que no estn en la misma clase, ni en una subclase, ni en el mismo paquete, se encuentran restringidos a los miembros pblicos de la clase. Si se observa la misma tabla desde el punto de vista de las filas, podemos describir los calificadores de los mtodos.

private
private String NumeroDelCarnetDeIdentidad; Las variables y mtodos de instancia privados slo pueden ser accedidos desde dentro de la clase.

No son accesibles desde las subclases de esa clase. Hay que resaltar una vez ms, que un mtodo de instancia de un objeto de una clase puede acceder a todos los miembros privados de ese objeto, o miembros privados de cualquier otro objeto de la misma clase. Es decir, que en Java el control de acceso existe a nivel de clase, pero no a nivel de objeto de la clase.

public
public void CualquieraPuedeAcceder(){} Cualquier clase desde cualquier lugar puede acceder a las variables y mtodos de instancia pblicos.

protected
protected void SoloSubClases(){} Slo las subclases de la clase y nadie ms puede acceder a las variables y mtodos de instancia protegidos. Los mtodos protegidos pueden ser vistos por las clases derivadas, como en C++, y tambin, en Java, por los paquetes. Todas las clases de un paquete pueden ver los mtodos protegidos de ese paquete. Esto difiere significativamente de C++, en donde los miembros protegidos solamente pueden ser accedidos por miembros de la misma clase o miembros de subclases.

package (fiendly, sin declaracin especfica)

void MetodoDeMiPaquete(){} Por defecto, si no se especifica el control de acceso, las variables y mtodos de instancia se declaran package (friendly, amigas), lo que significa que son accesibles por todos los objetos dentro del mismo paquete, pero no por los externos al paquete. Aparentemente, parece lo mismo que protected; la diferencia estriba en que la designacin de protected es heredada por las subclases de un paquete diferente, mientras que la designacin package no es heredada por subclases de paquetes diferentes. Debido a la complejidad y posible confusin respecto a los niveles de proteccin que proporciona Java para permitir el control preciso de la visibilidad de variables y mtodos, se puede generar otra tabla en base a cuatro categoras de visibilidad entre los elementos de clase:
private sin modificador protected public

Misma clase Misma subclase de paquete Misma no-subclase de paquete Subclase de diferente paquete No-subclase de diferente paquete

SI NO NO NO NO

SI SI SI NO NO

SI SI SI SI NO

SI SI SI SI SI

Y una gua de uso indicara tener en cuenta lo siguiente: Usar private para mtodos y variables que solamente se utilicen dentro de la clase y que deberan estar ocultas para todo el resto Usar public para mtodos, constantes y otras variables importantes que deban ser visibles

para todo el mundo Usar protected si se quiere que las clases del mismo paquete puedan tener acceso a estas variables o mtodos Usar la sentencia package para poder agrupar las clases en paquetes No usar nada, dejar la visibilidad por defecto (default, package) para mtodos y variables que deban estar ocultas fuera del paquete, pero que deban estar disponibles al acceso desde dentro del mismo paquete. Utilizar protected en su lugar si se quiere que esos componentes sean visibles fuera del paquete

9.