Objeto deus

Origem: Wikipédia, a enciclopédia livre.

Na programação orientada a objetos , um objeto deus (do inglês god object), também conhecido como objeto monstro, é um objeto que sabe demais ou faz demais. O objeto deus é um exemplo de um antipadrão em projetos de software. [1]

Uma técnica de programação comum é separar um problema grande em vários problemas menores (uma estratégia de divisão e conquista) e criar soluções para cada um deles. Uma vez resolvidos os problemas menores, o grande problema é resolvido como um todo. Portanto, um objeto destinado a resolver um pequeno problema precisa saber apenas sobre si mesmo e há apenas um pequeno conjunto de problemas que um objeto precisa resolver: seus próprios problemas.

Em contraste, um programa que emprega um objeto deus não segue essa abordagem. A maior parte da funcionalidade geral desse programa é codificada em um único objeto "onisciente", que mantém a maior parte das informações do programa inteiro e também fornece a maioria dos métodos para manipular esses dados. Como esse objeto contém muitos dados e requer tantos métodos, seu papel no programa se torna semelhante a deus (onisciente e abrangente). Em vez dos vários objetos do programa se comunicarem diretamente entre si, todos acabam dependendo do objeto deus para a maioria de suas informações e interações. Como esse objeto é fortemente acoplado a tantas outras partes do código, a manutenção se torna mais difícil do que seria em um projeto dividido de maneira mais uniforme. Por exemplo, alterações feitas no objeto deus para beneficiar uma certa rotina podem ter efeitos indesejados em outras rotinas não relacionadas. [1] [2]

Um objeto deus em programação orientada a objetos é análogo a não usar sub-rotinas em programação procedural, ou a usar muitas variáveis globais para armazenar informações de estado.

Enquanto a criação de um objeto deus é tipicamente considerada uma prática de programação incorreta, essa técnica é ocasionalmente usada in ambientes de programação rígidos (como microcontroladores), onde o aumento de desempenho e centralização do controle são mais importantes do que a manutenção e a elegância de programação.

Veja também[editar | editar código-fonte]

Referências

  1. a b coderhs. «God Class: Breaking Single Responsibility Principle». redpanthers.co (em inglês). Consultado em 19 de janeiro de 2019 
  2. Jones, Matthew. «God Objects - The Daily Software Anti-Pattern». exceptionnotfound.net (em inglês). Consultado em 19 de janeiro de 2019