En la programación orientada a objetos , un objeto de Dios es un objeto que sabe demasiado o hace demasiado . El objeto Dios es un ejemplo de antipatrón y olor a código . [1]
Una técnica de programación común es separar un gran problema en varios problemas más pequeños (una estrategia de divide y vencerás ) y crear soluciones para cada uno de ellos. Una vez que se resuelven los problemas más pequeños, se resuelve el gran problema en su conjunto. Por lo tanto, un objeto dado para un pequeño problema solo necesita conocerse a sí mismo. Del mismo modo, solo hay un conjunto de problemas que un objeto debe resolver: sus propios problemas. Esto también sigue el principio de responsabilidad única .
Por el contrario, un programa que emplea un objeto Dios no sigue este enfoque. La mayor parte de la funcionalidad general de un programa de este tipo está codificada en un único objeto "omnisciente", que mantiene la mayor parte de la información sobre todo el programa y también proporciona la mayoría de los métodos para manipular estos datos. Debido a que este objeto contiene tantos datos y requiere tantos métodos, su papel en el programa se vuelve como el de Dios (omnisciente y omnipresente). En lugar de que los objetos del programa se comuniquen entre sí directamente, los otros objetos dentro del programa dependen del único objeto Dios para la mayor parte de su información e interacción. Dado que este objeto está estrechamente acoplado a (referenciado por) gran parte del otro código, el mantenimiento se vuelve más difícil de lo que sería en un diseño de programación dividido de manera más uniforme. Los cambios realizados en el objeto en beneficio de una rutina pueden tener efectos no deseados en otras rutinas no relacionadas.
Un objeto de Dios es el análogo orientado a objetos de no usar subrutinas en lenguajes de programación de procedimientos , o de usar demasiadas variables globales para almacenar información de estado.
Mientras que la creación de un objeto Dios generalmente se considera una mala práctica de programación, esta técnica se usa ocasionalmente para entornos de programación ajustados (como microcontroladores ), donde el aumento del rendimiento y la centralización del control son más importantes que la facilidad de mantenimiento y la elegancia de la programación.
Ver también
- Código de ravioles : el patrón opuesto
Referencias
Otras lecturas
- Riel, Arthur J. (1996). "Capítulo 3: Topologías de aplicaciones orientadas a la acción vs. aplicaciones orientadas a objetos". Heurística de diseño orientado a objetos . Boston, Massachusetts: Addison-Wesley. ISBN 0-201-63385-X.
3.2: No cree clases / objetos divinos en su sistema. Sospeche mucho de una abstracción cuyo nombre contenga Controlador, Administrador, Sistema o Subsistema.
- Anti-Patrones y Peores Prácticas - Objetos Monstruos .