En la programación de computadoras , una orgía de objetos es una situación en la que los objetos no están suficientemente encapsulados a través del ocultamiento de información , lo que permite un acceso sin restricciones a sus partes internas. Esta es una falla común (o anti-patrón ) en el diseño orientado a objetos o en la programación orientada a objetos , y puede conducir a mayores necesidades y problemas de mantenimiento, e incluso a una complejidad que no se puede mantener.
Consecuencias
Los resultados de una orgía de objetos son principalmente una pérdida de los beneficios de la encapsulación, que incluyen:
- El acceso sin restricciones dificulta al lector razonar sobre el comportamiento de un objeto. Esto se debe a que el acceso directo a su estado interno significa que cualquier otra parte del sistema puede manipularlo, lo que aumenta la cantidad de código a examinar y crea medios para futuros abusos.
- Como consecuencia de la dificultad de razonamiento, el diseño por contrato es efectivamente imposible.
- Si mucho código se aprovecha de la falta de encapsulación, el resultado es un laberinto de interacciones difícilmente mantenible, comúnmente conocido como un nido de ratas o código espagueti .
- El diseño original se ve oscurecido por las interfaces excesivamente amplias con los objetos.
- Las amplias interfaces hacen que sea más difícil volver a implementar una clase sin molestar al resto del sistema. Esto es especialmente difícil cuando los clientes de una clase son desarrollados por un equipo u organización diferente.
Formularios
La encapsulación se puede debilitar de varias maneras, que incluyen:
- Declarando públicos a los miembros internos, o proporcionando acceso gratuito a los datos a través de métodos públicos de mutación (setter o getter).
- Proporcionando acceso no público. Por ejemplo, consulte: modificadores de acceso de Java y niveles de accesibilidad en C # [1]
- En C ++ , a través de algunos de los medios anteriores y declarando
friend
clases o funciones.
Un objeto también puede hacer que sus datos internos sean accesibles pasando referencias a ellos como argumentos a métodos o constructores de otras clases, que pueden retener referencias.
Por el contrario, los objetos que tienen referencias entre sí, aunque a veces se describen como una forma de orgía de objetos, no rompen por sí mismos la encapsulación.
Causas
Los miembros pueden ser declarados público para evitar el esfuerzo o por encima sintáctica de proporcionar adecuadas descriptores de acceso para ellos. Esto puede aumentar la legibilidad de la clase, pero a costa de las consecuencias descritas anteriormente.
Para algunos lenguajes, un miembro destinado a ser legible por otros objetos puede modificarse porque el lenguaje no tiene una construcción conveniente para el acceso de solo lectura.
Una orgía de objetos puede ser un síntoma de la codificación de un diseño inmaduro y anémico , cuando un diseñador no ha analizado suficientemente las interacciones entre objetos. También puede surgir por pereza o prisa en la implementación de un diseño, especialmente si un programador no se comunica lo suficiente con un diseñador, o por reticencia a revisar un diseño cuando surgen problemas, lo que también fomenta muchos otros anti-patrones.
Muchos programadores ven los objetos como repositorios de datos anémicos y los manipulan violando los principios de Ocultación de Información , Encapsulación y Diseño por Contratos .
Soluciones
En general, la encapsulación se rompe porque el diseño de otras clases lo requiere y se necesita un rediseño. Si ese no es el caso, puede ser suficiente volver a codificar el sistema de acuerdo con las mejores prácticas. Una vez que las interfaces se publican de forma irrevocable, puede que sea demasiado tarde para corregirlas.
Referencias
- ^ MSDN: Niveles de accesibilidad, Visual Studio .NET 2003 Archivado el 17 de abril de 2008 en Wayback Machine ).