Objeto todopoderoso

Objeto todopoderoso, en inglés God Object, es un Objeto que conoce demasiado o hace demasiado. El objeto todopoderoso es un ejemplo de antipatrón.

Historia

La idea básica detrás de la Programación Estructurada es: un gran problema se divide en muchos pequeños problemas (Estrategia Divide y Vencerás) y las soluciones son creadas para cada uno de ellos. Una vez que los pequeños problemas han sido resueltos, el gran problema ha sido resuelto como un todo. Sin embargo ha un solo objeto el cual necesita saber todo: el objeto en si. de esta manera, hay un solo grupo de problemas que el objeto debe resolver: sus propios problemas.

El Código del Objeto todopoderoso no sigue esta regla. En su lugar, la funcionalidad entera del programa esta codificada en un solo objeto que hace todo, el cual mantiene toda la información del programa entero y contiene todos los métodos y subrutinas para manipular los datos. Como el objeto contiene muchos datos y requiere muchos métodos, su rol en el programa se convierte en Objeto Todopoderoso (Abarca todo). En lugar de objetos comunicándose entre ellos directamente, los objetos en el programa se cuelgan del Objeto Todopoderoso para manejar su información e interacción. Como el Objeto Todopoderoso es referenciado por casi todo el código, el mantenimiento se vuelve mucho mas difícil, que el diseño del código de un programa mejor dividido

El objeto todopoderoso es el fallo de usar subrutinas de lenguajes procedurales en orientación a objetos o de usar demasiadas variables globales para almacenar información de estados

Crear un Objeto todopoderoso es típicamente considerado una mala practica de programación, esta técnica es usada ocasionalmente para entornos de programación ajustados, donde el aumento de rendimiento ligero y la centralización es mas importante que el mantenimiento y la elegancia de programación.

Referencias

• Ravioli code, patrones opuestos.

Enlaces externos

• Riel, Arthur J. (1996). «Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications». Object-Oriented Design Heuristics. Boston, MA: Addison-Wesley. ISBN 020163385X. «3.2: Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem.» 
• Anti-Patterns and Worst Practices – Monster Objects