Ocultación de información

En programación orientada a objetos el principio de ocultación hace referencia a que los atributos privados de un objeto no pueden ser modificados ni obtenidos a no ser que se haga a través del paso de un mensaje (invocación a métodos, ya sean estos funciones o procedimientos).

En informática, se conoce como principio de ocultación de información a la ocultación de decisiones de diseño en un programa susceptible de cambios con la idea de proteger a otras partes del código si estos se producen. Proteger una decisión de diseño supone proporcionar una interfaz estable que proteja el resto del programa de la implementación (susceptible de cambios). En los lenguajes de programación modernos el principio de ocultación de información se manifiesta de diferentes maneras, como por ejemplo la encapsulación.

Usos

El término encapsulación a menudo se utiliza como sinónimo de la ocultación de información, si bien existen ciertas diferencias entre ambos conceptos [1] Archivado el 14 de julio de 2007 en Wayback Machine.. Sin embargo parece que no existe un acuerdo sobre dichas diferencias, siendo común la idea de que la ocultación de información es el principio mientras que la encapsulación es la técnica. Un módulo de software oculta información encapsulándola en otro módulo u otra construcción con la que se comunica mediante una interfaz.

El uso más común de la ocultación de información es ocultar el diseño del almacenamiento físico de los datos, de manera que si dicho diseño es modificado solamente afecte a un pequeño subconjunto del programa total. Por ejemplo, si un punto tridimensional de coordenadas (x,y,z) es representado en un programa con tres variables escalares de coma flotante y posteriormente dicha representación es modificada a una variable array de tamaño 3, un módulo diseñado mediante la ocultación de información en principio protegería al resto del programa de este cambio.

En la programación orientada a objetos, la ocultación de información reduce los riesgos en el desarrollo de software al superar la dependencia del código de una implementación aún incierta (es una decisión de diseño) gracias a una interfaz bien construida. Los clientes de la interfaz realizan sus operaciones a través de ella de modo que si la implementación cambia, los clientes no tienen conocimiento de ello. Los autores de los patrones de diseño comentan las tensiones entre la herencia y la encapsulación en cuanto a que los diseñadores abusan de esta última (Gang of Four 1995:20). El peligro es expresado del siguiente modo:

"Puesto que la herencia expone a una subclase los detalles de la implementación de su clase padre, a menudo se dice que 'la herencia rompe la encapsulación'". (Gang of Four 1995:19)

Ejemplo

Por ejemplo, una marca de coches puede ofertar una versión de lujo de un cierto modelo del que también ofrecen una versión básica. La versión de lujo monta un motor más potente que la básica. Sin embargo, los ingenieros han realizado el diseño de ambos motores de forma que la "interfaz" sea la misma: ambos motores encajan en la carrocería compartida por los dos modelos, están acoplados a la misma transmisión y tienen los mismos controles. La diferencia entre ellos reside en que la versión de lujo, más potente, es de mayor cilindrada y va alimentado mediante inyección.

Además de un motor más potente, la versión de lujo ofrecería otras opciones como un mejor sistema de sonido, asientos más cómodos, una mejor suspensión con neumáticos más anchos y diferentes colores para la carrocería. Pese a todos estos cambios, el coche en sí es el mismo. El sistema de sonido reemplaza a la radio básica, que es de por sí un módulo; los asientos van montados sobre la misma base que los básicos, etc.

Los ingenieros han diseñado el coche dividiendo el trabajo en distintas tareas asignadas a sus respectivos equipos. Cada equipo diseña entonces sus componentes con la única restricción de adaptarse a un determinado estándar o interfaz que asegure la cohesión del resultado final.

Como se ve en el ejemplo, la ocultación de información supone mayor flexibilidad. Esta flexibilidad permite al programador modificar diferentes funciones del programa para adaptarlo a las necesidades de los usuarios. Si durante el diseño se han seguido estas pautas, los cambios evolutivos son mucho más fáciles de realizar ya que suelen tener un alcance local y no global.

Volviendo a los coches, otro ejemplo es la interfaz del conductor con la máquina, compuesta por pedales, volante, testigos, palancas... Salvando las distancias, es común entre todos los coches, de manera que cuando una persona aprende a conducir y recibe su permiso de conducción no tiene que volver a obtenerlo si cambia de coche.

Historia

El concepto de ocultación de información apareció documentado por primera vez en un artículo de David Parnas, "On the Criteria to Be Used in Decomposing Systems Into Modules", publicado en "Communications of the ACM" en diciembre de 1972.

• Datos: Q15912075