Dicas / conselhos sobre como reduzir o uso de classes de "gerente"?

Às vezes, ouço dizer que ter muitas classes de "gerente" no design do seu programa é um cheiro de código e adiciona uma camada desnecessária de complexidade. Para mim, faz sentido que as pessoas queiram usar classes de gerente para manipular e controlar objetos de um contexto que faça sentido para elas, mas descobrir como fazer uma solução funcionar sem elas pode ser confuso.

Devemos realmente evitar as classes de gerente o máximo possível? Além disso, quais artigos / artigos devo ler sobre como implementar uma solução alternativa para casos gerais / comuns em que esses gerentes podem ser removidos?

Talvez haja duas razões pelas quais este é um cheiro de código. Um motivo é que isso pode significar que você não possui objetos de domínio, mas objetos de valor que apenas armazenam dados para manipulação por classes de controlador ou gerente. Isso é realmente muito comum e equivale a programação procedural em uma linguagem OO. Os "muitos gerentes" podem ser uma dica de que você precisa integrar lógica de estado, validação e outras preocupações diretas nos objetos do domínio para que eles realmente encapsulem algo. É claro que existem dicas maiores, como o fato de você não ter outros métodos além de getter / setters.

A outra razão para o cheiro do código é que isso pode significar que os objetos do seu domínio não se relacionam muito bem. Por exemplo, se você tem uma classe Conta que realmente não sabe nada sobre a classe Transação, exceto que se chama Transação e pode haver mais de uma delas, então novamente você não tem uma implementação de domínio comercial muito vibrante. Por exemplo, SavingsAccount talvez deva saber que não pode aceitar uma DebitTransaction se o accountStatus estiver fechado. Muitas implementações deixariam isso para o gerente.

Ter muitas classes "gerenciador" geralmente é um sintoma de um modelo de domínio anêmico , em que a lógica do domínio é içada para fora do modelo de domínio e, em vez disso, colocada em classes gerenciadoras, que mais ou menos equivalem a scripts de transação . O perigo aqui é que você está basicamente voltando à programação procedural - que por si só pode ou não ser uma coisa boa, dependendo do seu projeto - mas o fato de não ter sido considerado ou pretendido é a imo do "cheiro do código".

Seguindo o princípio do "especialista em informações" , uma operação lógica deve residir o mais próximo possível dos dados necessários. Isso significaria mover a lógica do domínio de volta para o 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 scripts de transação alterando o estado do modelo de domínio de fora.

O maior problema com as classes de gerente é que elas representam apenas essa vaga idéia do que a classe deve fazer. Se você chamar um gerente de algo, ele poderá fazer tudo o que estiver relacionado ao que estiver gerenciando. Suponho que em alguns contextos isso pode ser bom, mas eu diria que em quase todos os casos não é isso que você deseja. Você quer que alguém seja capaz de olhar para o nome da classe e não apenas ter uma boa ideia do que a classe faz, mas também o que ela não faz.

Outro problema com as classes de gerenciador é que torna muito difícil decidir para onde a funcionalidade deve ir. Quando há muitas classes de gerenciadores, frequentemente há muita sobreposição de funcionalidades entre as classes de gerenciadores. Você precisa descobrir qual classe deve implementar essa funcionalidade sobreposta e, é claro, alguém escolheria de maneira diferente. Portanto, quando eles procuram a funcionalidade e não a veem onde esperam, vão em frente e a reimplementam onde acham que ela pertence, porque não estão cientes da existência da outra implementação. Em outras palavras, as classes de gerentes levam a projetos difíceis de entender e freqüentemente complicados.