6 de junio de 2008

Una nueva forma de ver el paradigma orientado a objetos - Parte 2

Encapsulamiento: la forma tradicional de verlo y la nueva forma de verlo

Mi paraguas orientado a objetos.

En mi clases de diseño de orientado a objetos, frecuentemente pregunto a mis estudiantes, “Quien ha escuchado que encapsulamiento es definido como ocultamiento de datos?”, casi todos levantan la mano.

Entonces procedo a contar una historia de mi paraguas. Ten en mente que vivo en Seatle, la cual tiene una reputación de ser más húmedo de lo que es, pero es aún un lugar muy húmedo en otoño, invierno y primavera. Aquí los paraguas y abrigos son nuestros amigos personales!

Déjame contarte acerca de mi gran paraguas. Es bastante grande para cubrirme!, de hecho, 3 o 4 personas puedes cubrirse conmigo. Mientras estamos cubiertos, manteniéndonos alejados de la lluvia, puedo moverme de un lugar a otro. Tiene un sistema de sonido para mantenerme entretenido mientras me mantengo seco. Sorprendentemente, puede también acondicionar el aire para que este más caliente o más frío. Es un paraguas genial.

Mi paraguas es conveniente. Se queda ahí esperando por mi. Tiene ruedas para que no tenga que estarlo cargando. Ni siquiera lo tengo que empujar porque lo puede hacer por si mismo. Algunas veces, abriré la parte superior de mi paraguas para dejar pasar los rayos solares. (El porque del que este usando mi paraguas cuando esta asoleado afuera esta fuera de mi compresión).

En Seatle, hay cientos de miles de paraguas de todos colores.

La mayoría de las personas les llama autos.

Pero pienso en el mío como un paraguas porque un paraguas es algo usado para mantenernos fuera de la lluvia. Muchas veces, mientras estoy esperando afuera por alguien para conocerlo, me siento en mi “paraguas” para mantenerme seco!

Las definiciones pueden limitarnos

Por supuesto que un carro no es realmente un paraguas. Si, puedes usarlo para mantenerte alejado de la lluvia, pero esa es una visión muy limitada de un auto. De la misma manera, el encapsulamiento es no solamente para el ocultamiento de datos. Esa es una visión muy limitada de encapsulamiento. Pensarlo de esa manera nos limita al hacer nuestros diseños.

Como pensar acerca del encapsulamiento

Encapsulamiento debería ser enseñado como “cualquier tipo de ocultamiento”. En otras palabras, puede ocultar datos. Pero también puede ocultar implementaciones, clases derivadas o cualquier cantidad de cosas. Considera el diagrama monstrado en la figura 8-1.

Multiples niveles de encapsulamiento

Figura 8-1


La figura 8-1 muestra varios tipos de encapsulamiento:

· Encapsulamiento de datos – Los datos en Point, Line, Saquer y Circle están ocultos.

· Encapsulamiento de métodos – Por ejemplo, el método setLocation de Circle.

· Encapsulamiento de Subclases – Los clientes de Shape no ven Points, Lines, Squares o Circles.

· Encapsulamiento de otros objetos: Nadie más que Circle esta enterado de la existencia de xxCircle.

Un tipo de encapsulamiento es alcanzado cuando hay una clase abstracta que se comporta polifórmicamente sin que el cliente se entere de que tipo en concreto es el que está usando. Además, adaptando interfaces oculta lo que esta detrás del objeto adaptado.

La ventaja de esta nueva definición

La ventaje de ver el encapsulamiento de esta manera nos da una mejor manera de separar (descomponer) los programas. Las capas de encapsulamiento llegan a ser las interfaces que debo diseñar. Encapsulando varios tipos de Shapes, puedo añadir nuevos sin cambiar nada del programa del cliente que los usa. Encapsulando XXCircle detrás de Circle, puedo cambiar la implementación en un futuro si lo eligo o es necesario.

Herencia como concepto vs herencia para la reutilización

Cuando el paradigma orientado a objetos fue por primera vez presentado, la reutilización de clases fue promocionada como uno de los más grandes beneficios. La reutilización usualmente era lograda creando clases y luego derivando nuevas clases basadas en las clases base. Por lo tanto el término clases especializadas era para esas subclases que fueron derivadas de otras clases (otras clases se refiere también a un término conocido como clases generalizadas).

No estoy poniendo en duda la importancia de esto, en lugar estoy proponiendo lo que creo es una forma más poderosa de usar la herencia. En el ejemplo de arriba, puedo hacer mis diseños basados en diferentes tipos especiales de Shapes (Estos son, Points, Lines, Squares y Circles). Sin embargo, esto probablemente no oculte los casos especiales cuando yo piense en usar Shapes. Puede que tome ventaja del conocimiento de estas clases concretas.

Si por el contrario, pienso en Shapes como una forma de clasificar Points, Lines Squares y Circles, puedo más fácilmente pensar acerca de estos como un TODO. Esto hará más probable que yo diseñe por interfaz (Shapes). También significa que si obtengo un nuevo tipo de Shape, será poco probable que me vea en una posición de dificultad de mantenimiento. (Porque el código del cliente no conoce con que tipo en concreto de Shape está tratando).

Pronto pondré la tercera parte,

Un saludote !

No hay comentarios.: