As classes do gerenciador podem ser um sinal de arquitetura ruim?

As classes do gerenciador podem ser um sinal de uma arquitetura ruim, por alguns motivos:

• Identificadores sem significado

  O nome FooManager não diz nada sobre o que a classe realmente faz , exceto que de alguma forma envolve Foo instances. Dar à turma um nome mais significativo elucida sua verdadeira finalidade, o que provavelmente levará à refatoração.

• Responsabilidades fracionárias

  De acordo com o princípio da responsabilidade única, cada unidade de código deve atender exatamente a um propósito. Com um gerente, você pode estar dividindo artificialmente essa responsabilidade.

  Considere um ResourceManager que coordena as vidas úteis e o acesso a Resource instâncias. Um aplicativo tem um único ResourceManager através do qual adquire Resource instâncias. Nesse caso, não há motivo real pelo qual a função de ResourceManager instance não possa ser atendida por métodos estáticos na classe Resource .

• Abstração não estruturada

  Geralmente, um gerente é apresentado para abstrair os problemas subjacentes com os objetos que gerencia. É por isso que os gerentes se prestam a abusos como band-aids para sistemas mal projetados. A abstração é uma boa maneira de simplificar um sistema complexo, mas o nome “gerenciador” não oferece nenhuma pista sobre a estrutura da abstração que ela representa. É realmente uma fábrica, um proxy ou outra coisa?

Naturalmente, os gerentes podem ser usados para mais do que apenas o mal, pelas mesmas razões. Um EventManager - que é realmente um Dispatcher - armazena eventos de fontes e os envia para destinos interessados. Neste caso, faz sentido separar a responsabilidade de receber e enviar eventos, porque um indivíduo Event é apenas uma mensagem sem noção de proveniência ou destino.

Escrevemos Dispatcher de Event instâncias essencialmente pela mesma razão que escrevemos GarbageCollector ou Factory :

Um gerente sabe o que sua carga útil não precisa saber.

Essa, eu acho, é a melhor justificativa para criar uma classe de gerência. Quando você tem algum objeto de "carga útil" que se comporta como um valor, ele deve ser o mais estúpido possível para que o sistema geral permaneça flexível. Para fornecer significado a instâncias individuais, você cria um gerente que coordena essas instâncias de maneira significativa. Em qualquer outra situação, os gerentes são desnecessários.

Gerentes podem ser um sinal de uma arquitetura ruim, mas na maioria das vezes eles são apenas um sinal de uma incapacidade em nome do designer para criar nomes melhores para seus objetos, ou simplesmente apenas um reflexo do fato de que a língua inglesa (e qualquer linguagem humana) é adequada para a comunicação de conceitos práticos cotidianos, e não de conceitos altamente abstratos e altamente técnicos.

Um exemplo simples para ilustrar o meu ponto: antes de o padrão de fábrica ser nomeado, as pessoas o usavam, mas não sabiam como chamá-lo. Então, alguém que teve que escrever uma fábrica para sua classe Foo pode ter chamado FooAllocationManager . Isso não é um projeto ruim, é apenas falta de imaginação.

E então alguém precisa implementar uma classe que mantenha muitas fábricas e as distribua para vários objetos que as solicitam; e ele chama sua classe FactoryManager porque a palavra Industry simplesmente nunca ocorreu a ele, ou ele achou que não seria legal porque nunca ouvira falar de algo parecido na programação. Mais uma vez, um caso de falta de imaginação.

Ter várias aulas de "gerente" geralmente é um sintoma de um modelo de domínio anêmico , em que a lógica do domínio é içada fora do modelo de domínio e, em vez disso, colocados em classes de gerenciadores, o que equivale mais ou menos a scripts de transação . O perigo aqui é que você está basicamente revertendo a programação procedural - que em si pode ou não ser uma coisa boa dependendo do seu projeto - mas o fato de que não foi considerado ou pretendido é o problema real imo.

Seguindo o princípio do "especialista em informações" , uma operação lógica deve residir o mais próximo possível aos dados que requer como possível. Isso significaria mover a lógica de domínio de volta ao modelo de domínio, para que sejam essas operações lógicas que tenham um efeito observável no estado do modelo de domínio, em vez de "gerentes" alterarem o estado do modelo de domínio do lado de fora.

Resposta curta: depende .

Existem várias formas distintas de "classes de gerentes", algumas são boas, outras são ruins, e para a maioria delas depende muito do contexto se a introdução de uma classe de gerentes é a coisa certa. Um bom ponto de partida para obtê-los corretamente é seguir o princípio de responsabilidade única - se você souber exatamente o que cada um de seus gerentes de classe é responsável por (e quais não), você terá muito menos problemas em entendê-los.

Ou para responder à sua pergunta diretamente: não é o número de turmas gerenciais indicando uma arquitetura ruim, mas ter muitas delas com responsabilidades pouco claras ou lidar com muitas preocupações.

Embora seja fácil dizer que eles são inerentemente indicativos de um mau design, eles podem trazer muito bem e reduzir a complexidade do código e outros códigos clichês ao longo do projeto, abrangendo uma única tarefa e responsabilidade universalmente. / p>

Embora a prevalência de gerentes possa ser atribuída ao fraco julgamento do design, eles também podem lidar com as más decisões de design ou problemas de incompatibilidade com outros componentes em um componente de design ou componentes de interface do usuário de terceiros ou com serviços da Web de terceiros. uma interface estranha como exemplos.

Estes exemplos demonstram onde eles são extremamente úteis para certas situações, reduzindo a complexidade geral e promovendo um baixo acoplamento entre vários componentes e camadas, encapsulando o "código feio" em um único lugar. Uma pegadinha, porém, seria que as pessoas acham tentador fazer os Gerentes como solteiros, eu aconselharia contra isso, e é claro, como outros sugeriram que o Princípio da Responsabilidade Única deveria ser sempre seguido.

Can manager classes be a sign of bad architecture?

Você respondeu à sua pergunta: eles não precisam ser um sinal de design ruim.

Exceto pelo exemplo da sua pergunta com o EventManager, há outro exemplo: no MVC padrão de design, o apresentador pode ser visto como um gerenciador para as classes de modelo / visualização.

No entanto, se você usar mal um conceito, então é um sinal de um projeto defeituoso e, possivelmente, de arquitetura.

Quando a classe tiver "Gerente" no nome, cuidado com o deus class problema (um com muitas responsabilidades). Se é difícil descrever o que uma classe é responsável por seu nome, isso é um sinal de alerta de projeto.

Classes de gerentes ruins de lado, o pior nome que já vi foi "DataContainerAdapter"

"Dados" devem ser outra dessas substrings banidas em nomes - são todos dados, "dados" não são muito úteis na maioria dos domínios.

Classes de gerente - assim como quase qualquer aula que termine com "-er" - são maus e não têm nada a ver com OOP. Então, para mim, é um sinal de má arquitetura.

Por quê? O nome "-er" implica que um designer de código tomou alguma ação e o converteu para a classe. Como resultado, temos uma entidade artificial que não reflete nenhum conceito tangível, mas alguma ação. Isso soa muito processual.

Além disso, geralmente essas classes pegam alguns dados e operam sobre elas. Esta é uma filosofia de dados passivos e procedimentos ativos e encontrou seu lugar na programação processual. Se você perceber isso, não há nada de ruim nas classes Manager, mas não é OOP.

O pensamento de objeto implica que os objetos fazem coisas para si mesmos. Descubra seu domínio , crie redes semânticas , deixe seus objetos serem organismos vivos, seres humanos inteligentes e responsáveis.

Esses objetos não precisam ser controlados. Eles sabem o que fazer e como fazer. Então, as classes Manager quebram os princípios OOP duas vezes. Além de ser uma classe "-er", controla outros objetos. Mas isso depende do gerente. Ele controla - ele é um mau administrador. Se ele coordena - ele é um bom gerente. É por isso que uma letra "C" em MVC deve ser escrita como "Coordenador" .

A resposta correta para esta pergunta é:

1. Depende.

Todas as situações que você encontrará ao escrever o software são diferentes. Talvez você esteja em uma equipe onde todos sabem como as classes de gerentes funcionam internamente? Seria completamente louco não usar esse design. Ou se você está tentando empurrar o gerente-design para outras pessoas, caso em que pode ser uma má ideia. Mas isso depende de detalhes exatos.