É o uso de *** Helper ou *** Classes util contendo apenas métodos estáticos um AntiPattern

14

Frequentemente sou confrontado com classes auxiliares ou utilitárias em Java ou em qualquer tipo de linguagem. Então eu estava me perguntando se isso é algum tipo de Anti-Padrão e a existência desse tipo de aula é apenas uma falta de falhas no design e na arquitetura de um Software.

Muitas vezes, essas classes são confinadas usando apenas métodos estáticos, que fazem muito das coisas. Mas, na maioria das vezes, é de fato dependente do contexto e do estado.

A minha pergunta é, qual é a sua opinião sobre este tipo de classes auxiliares / estáticas porque a vantagem é, obviamente, a invocação rápida usando apenas o nome da classe.

E em que nível de abstração você evitaria usar esse tipo de classe?

Na minha opinião, a palavra-chave "static" deve ser permitida apenas na declaração de uma classe (Java) e não para métodos. Na minha opinião é que, ao usá-lo dessa maneira, poderia ser uma boa alternativa e um meio para ser capaz de combinar Paradigmas Procuedural e OO em Java e evitar a falta de uso da palavra-chave.

Adições devido às respostas:

No começo, eu acho que é completamente legal ser capaz de combinar diferentes paradigmas e até mesmo usar linguagens de script interpretadas em tempo de execução dentro de código compilado por máquina ou vm.

Minha experiência é que durante o processo de desenvolvimento de um projeto desse tipo de ajudantes e utilitários ou qualquer que seja o nome, estão crescendo, crescendo e sendo usados em todos os cantos esquecidos da codebase, que foi originalmente projetada para ser modular e flexibel. E devido à falta de tempo para fazer refatorações ou pensar no design novamente, você só piorará muito ao longo do tempo.

Acho que static deve ser removido do Java. Especialmente agora, onde é possível usar elementos de linguagem funcional ainda mais sofisticados.

    
por Diversity 18.07.2018 / 21:50
fonte

5 respostas

19

Bem, o Java não possui funções livres, assim você é forçado a colocá-las como funções estáticas em alguma classe pro-forma. Uma alternativa necessária nunca é um anti-padrão, embora possa faltar elegância.

Em seguida, não há nada de errado com funções gratuitas. Na verdade, o uso de funções livres reduz o acoplamento, já que eles só têm acesso à interface pública em vez de todos os detalhes.

É claro que o uso de funções livres / estáticas não alivia de forma alguma os perigos do estado mutável compartilhado, especialmente global.

    
por 18.07.2018 / 23:12
fonte
15

O utilitário estático ou as funções auxiliares não são um anti-padrão se seguirem algumas diretrizes:

  1. Eles devem estar livres de efeitos colaterais

  2. Eles são usados para um comportamento específico do aplicativo que não pertence à classe ou classes nas quais essas funções operam

  3. Eles não exigem nenhum estado compartilhado

Casos de uso comuns:

  • Formatando datas de uma maneira específica do aplicativo
  • Funções que tomam um tipo como entrada e retornam um tipo diferente.

Por exemplo, em um aplicativo em que trabalhei, os usuários mantêm entradas de diário para suas atividades. Eles podem especificar uma data de acompanhamento e fazer o download de um lembrete de evento. Criamos uma classe de utilitário estática para obter uma entrada de diário e retornar o texto bruto para um arquivo .ics.

Não exigiu nenhum estado compartilhado. Ele não alterou nenhum estado e a criação de um evento do iCal certamente era específica do aplicativo e não pertencia à classe de entrada do diário.

Se as funções estáticas ou classes de utilitário tiverem efeitos colaterais ou precisarem de estado compartilhado, recomendo reavaliar esse código, pois ele introduz um acoplamento que pode ser difícil de burlar para o teste de unidade.

    
por 19.07.2018 / 14:21
fonte
4

Dependerá da sua abordagem. Muitos aplicativos são escritos com uma mentalidade mais funcional, em oposição à clássica (incluindo grande parte do conjunto de sites em que você está).

Com essa mentalidade, haverá muitos métodos de utilitário em classes de trabalho que podem ser agrupados como métodos estáticos. Eles são alimentados / usados mais perto de objetos simples que só armazenam dados e são repassados.

É uma abordagem válida e pode funcionar muito bem, especialmente em escala.

    
por 18.07.2018 / 22:34
fonte
2

Pessoalmente, acho que a única parte importante sobre essas aulas de ajuda é que elas sejam privadas. Além disso - eles são estritamente uma boa ideia (aplicada com moderação).

A maneira que eu penso sobre isso - é se na implementação de uma classe (ou função) - algo como isso é útil, e torna essa implementação mais clara, como isso poderia ser ruim? E, muitas vezes, é crítico definir essas classes auxiliares privadas para permitir a integração e o uso de outros algoritmos que dependem de dados que estão em uma determinada forma.

A rotulagem de 'ajudante' é uma pequena questão de gosto pessoal, mas é um conto que ajuda na implementação e não é de interesse / uso para um público mais amplo. Se é isso que faz sentido - vá em frente!

    
por 18.07.2018 / 22:24
fonte
1

A prevalência de static classes auxiliares baseia-se em um equívoco. Só porque chamamos classes com apenas static métodos "classes de utilitários" não significa que não é permitido escrever comportamento comum em POJOs.

static classes auxiliares são anti-padrão por três motivos:

  1. O acesso estático a esses métodos auxiliares oculta dependências . Se essas "classes de utilidade" fossem POJOs, você poderia injetá-las em uma classe dependente como parâmetros de construtor , o que tornaria a dependência óbvia para qualquer usuário de uma classe dependente.

  2. O acesso estático a esses métodos auxiliares causa um acoplamento strong . Isso significa que o código usando os métodos auxiliares é difícil de reutilizar e (como um efeito colateral) hart to test.

  3. Especialmente se eles mantêm estado , são apenas variáveis globais . E esperamos que ninguém argumente que as variáveis globais são boas ...

As classes auxiliares estáticas fazem parte do anti-padrão STUPID code .

Global state is unrelated to the question, – max630

O OP escreveu:

But mostly it is indeed context dependent and statefull.

As construções estáticas statefull são estados globais.

any kind of code can use it. – max630

Sim, de causa. E quase todos os aplicativos precisam de algum tipo de estado global .

Mas estado global ! = variável global .

Você pode criar estado global com técnicas OO via injeção de dependência Mas você não pode evitar estado global com estruturas estáticas de estado que são variáveis globais em o fundo.

    
por 18.07.2018 / 22:57
fonte