Buenas Prácticas: Encapsular, encapsular y encapsular.

Quisiera poner un ejemplo bastante gráfico para dejar patente la importancia de la encapsulación. Es muy bonito el concepto de encapsulación, todos lo conocemos y lo utilizamos, pero seguramente no todas las veces que deberí­amos. Inicio el ejemplo:

Tenemos un objeto que controla cual es el tabulador activo en una tí­pica ventana con pestañas, como esta. Hemos encapsulado nuestro objeto y le hemos creado un método píºblico que se encarga que desde fuera del objeto poder elegir cual es la pestaña activa.

Algo así­ como: (código C#)

ObjetoTabulador tab = new ObjetoTabulador();
tab.SetPestaña(3); // 3 es el níºmero de la pestaña que vamos a activar

Vale, está claro que esto funciona, pero no está bien encapsulado. Diseñando este objeto así­ estamos dando por hecho que sabemos lo que hace por dentro el ObjetoTabulador. Si yo quiero activar la tercera pestaña le paso un 3 y ese es el dato que se utiliza internamente.

¿No creéis que serí­a mejor solución la siguiente?

ObjetoTabulador tab = new ObjetoTabulador();
tab.SetPestaña(ObjetoTabulador.Pestañas.Informes); // informes corresponde a la pestaña de informes en el tabulador de la imagen

¿Qué ha cambiado aquí­? Pues que en lugar de pasarle el níºmero le estamos pasando un tipo enumerado que aporta el mismo ObjetoTabulador y es el que internamente va a tratar cual es la pestaña a activar. ¿Quién dice que mañana la pestaña de Informes va a seguir en la tercera posición? Si esto cambiara todas las llamadas que activan el tabulador por níºmero pasarí­an a ser inconsistentes, mientras que pasándole el tipo enumerado seguirí­a activándose la pestaña que le habí­amos indicado. Por cierto, pasándole un í­ndice estamos dejando al descubierto que internamente estamos gestionando las pestañas con una lista.

Este error viene dado muchas veces porque cuando estamos tratando con objetos que nosotros mismos creamos y a los cuales tenemos acceso directo a partir de nuestra propia aplicación nos acostumbramos a que sabemos lo que hacen internamente y lo podemos cambiar. No resulta esta la mejor manera de programar, a la hora de desarrollar hay que pensar siempre en que los componentes que hacemos han de poder funcionar de forma totalmente independiente y que no debemos necesitar mirar su código interno para saber qué es lo que hacen.

Si con un objeto tan tonto como un control de tabulación la mejora es tan grande, (recuerdo que hemos evitado los errores que se generarí­an al modificar el orden de las pestañas, hemos elevado la mantenibilidad del código y la productividad del desarrollo), doy por hecho que os hacéis a la idea de lo que supondrí­a tener en cuenta estas cosas al trabajar con objetos más complicados.

Es curioso porque cuando desarrollamos DLL’s de componentes o de objetos el concepto de encapsulación lo tenemos más claro, pero cuando utilizamos objetos propios de los cuales tenemos acceso al código fuente, se nos olvida lo de la encapsulación.

No hay que dar por hecho que para entender lo que hace una clase hay que mirar su código.

Saludos.

Miguel.

This entry was posted in Buenas Prácticas, Gestión del Mantenimiento, Programación. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current ye@r *

Please copy the string c1sgrV to the field below: