orgía de objetos

En programación informática , una orgía de objetos es una situación en la que los objetos no están suficientemente encapsulados mediante la ocultación de información , lo que permite un acceso sin restricciones a su interior. Este es un fallo común (o antipatrón ) en el diseño orientado a objetos o la programación orientada a objetos , y puede generar mayores necesidades y problemas de mantenimiento, e incluso una complejidad inmanejable.

Los resultados de una orgía de objetos son principalmente una pérdida de los beneficios de la encapsulación, entre los que se incluyen:

• El acceso sin restricciones dificulta que un lector comprenda el comportamiento de un objeto. Esto se debe a que el acceso directo a su estado interno implica que cualquier otra parte del sistema puede manipularlo, lo que aumenta la cantidad de código a examinar y crea la posibilidad de futuros abusos.
• Como consecuencia de la dificultad del razonamiento, el diseño por contrato resulta prácticamente imposible.
• Si gran parte del código se aprovecha de la falta de encapsulación, el resultado es un laberinto de interacciones difícilmente mantenible, comúnmente conocido como nido de ratas o código espagueti .
• El diseño original queda oscurecido por las interfaces excesivamente amplias para acceder a los objetos.
• Las interfaces complejas dificultan la reimplementación de una clase sin afectar al resto del sistema. Esto resulta especialmente complicado cuando los clientes de una clase son desarrollados por un equipo u organización diferente.

La encapsulación puede verse debilitada de varias maneras, entre ellas:

• Declarando públicos a los miembros internos o proporcionando acceso gratuito a los datos mediante métodos mutadores públicos (setter).
• Al proporcionar acceso no público. Por ejemplo, véase: Modificadores de acceso de Java y niveles de accesibilidad en C# ^{[ 1 ]}
• En C++ , a través de algunos de los medios mencionados anteriormente, y declarando friendclases o funciones.

Un objeto también puede hacer accesibles sus datos internos pasando referencias a ellos como argumentos a métodos o constructores de otras clases, que pueden conservar dichas referencias.

Por el contrario, el hecho de que los objetos contengan referencias entre sí, aunque a veces se describa como una forma de orgía de objetos, no rompe por sí solo la encapsulación.

Se pueden declarar miembros públicos para evitar el esfuerzo o la complejidad sintáctica que supone proporcionarles los métodos de acceso adecuados . Esto puede mejorar la legibilidad de la clase, pero a costa de las consecuencias descritas anteriormente.

En algunos lenguajes de programación, un miembro destinado a ser legible por otros objetos puede hacerse modificable porque el lenguaje no dispone de una estructura conveniente para el acceso de solo lectura.

Una sobrecarga de objetos puede ser síntoma de una programación basada en un diseño inmaduro y deficiente , cuando el diseñador no ha analizado suficientemente las interacciones entre los objetos. También puede surgir de la pereza o la prisa en la implementación del diseño, especialmente si el programador no se comunica lo suficiente con el diseñador, o de la reticencia a revisar el diseño cuando surgen problemas, lo que a su vez fomenta muchos otros antipatrones.

Muchos programadores consideran 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 contrato .

En general, la encapsulación se rompe porque el diseño de otras clases lo requiere, y es necesario rediseñarla. Si este no es el caso, puede ser suficiente con volver a codificar el sistema siguiendo las mejores prácticas. Una vez que las interfaces se publican de forma irreversible, puede ser demasiado tarde para corregirlas.

• PerlDesignPatterns.com