O que é um ajudante? É um padrão de design? É um algoritmo?

Uma classe Helper é um cheiro de código menos conhecido em que um codificador identificou algumas operações diversas e comumente usadas e tentou torná-las reutilizáveis agrupando-as juntos em um agrupamento não natural. Os desenvolvedores sucessivos entraram no projeto e não perceberam que a classe auxiliar existe e, consequentemente, reescreveram as mesmas operações comuns ou até criaram mais classes auxiliares.

Mas, falando sério, o principal problema com as classes auxiliares é que geralmente são operações que atuam em uma classe específica, o que obviamente significa em termos OO que estão sofrendo de um caso agudo de Inveja de recurso . Essa falha em empacotar o comportamento com os dados sobre os quais atua é o motivo pelo qual os desenvolvedores tantas vezes (na minha experiência) não conseguem encontrá-lo.

Além disso, como você já identificou SomethingSomethingHelper é na verdade um nome terrível . Não é descritivo e não dá nenhuma idéia real do tipo de operações que a classe faz (ajuda?), O que também significa que não é óbvio ao adicionar novos comportamentos, quer pertençam à classe Helper ou não. crie essas classes ao longo das linhas de comportamento relacionado que agrupam logicamente e, em seguida, renomeie as novas classes para refletir o que elas fazem.

Comentários

• Bonito certifique-se de que SomethingSomethingHelper não é o nome real da classe. Se é ‘ um cheiro de código ou não, depende de quão específico a classe auxiliar é, já que classes auxiliares como Math não são um cheiro de código.
• @RobertHarvey – Enh, a maioria das que eu ‘ vi foram chamados de SomethingSomethingHelper. Caramba, eu ‘ estou olhando para uma classe agora chamada HelperMethods no <company>.Helpers namespace. Para mim, um classe está no mesmo intervalo que *Manager.
• @Telastyn: Talvez ‘ é uma experiência, então. Eu ‘ olhei as classes auxiliares em meu projeto atual (existem várias) e todas têm nomes significativos. Há ‘ s apenas um que ‘ s com sufixo Helper, e eu acho que ‘ s para separá-lo de uma classe no .NET Framework com o mesmo nome. Eu ‘ d considero *Helper aceitável se * for algo significativo. HelperMethods é apenas uma falta de imaginação; deve haver pelo menos depósitos conceituais específicos.
• @RobertHarvey – Você ‘ provavelmente está certo. Toda a minha carreira usando linguagens modernas foi limpar destroços de trens.
• Há um subconjunto deles, chamado ” funções auxiliares “, que são realmente úteis e um bom padrão.Por exemplo, um conjunto comum de linhas que, de outra forma, precisariam ser repetidas dentro de uma função – um exemplo de onde elas aparecem é quando você precisa de um do..while loop em Python, que a linguagem não ‘ não é compatível (consulte o segundo exemplo aqui ). Outra seria uma estrutura if / elif /…/ else, mas precisa repetir um caso na parte superior e inferior. Se possível, eles devem se tornar locais para essa função e geralmente não devem ser chamados de ” helper “.

Um auxiliar é uma classe ou método adicional inofensivo, desde que complemente um componente externo. Quando faz o contrário, indica um design ruim porque o código foi excluído de sua autoridade, se é que existe alguma autoridade.

Aqui está um exemplo de um auxiliar inofensivo, eu uso um método chamado FindRep que conta o número de zeros à esquerda.

 digits = digits.Remove(0, TextHelper.FindRep("0", digits, 0, digits.Length - 2));  

O método auxiliar é muito simples, mas muito inconveniente de copiar e colar, e a estrutura não oferece nenhuma solução.

 public static int FindRep(char chr, string str, int beginPos, int endPos) { int pos; for (pos = beginPos; pos <= endPos; pos++) { if (str[pos] != chr) { break; } } return pos - beginPos; }  

E aqui está um exemplo de ajudante ruim:

 public static class DutchZipcodeHelper { public static bool Validate(string s) { return Regex.IsMatch(s, @"^[1-9][0-9]{3}[A-Z]{2}$", RegexOptions.IgnoreCase); } } public class DutchZipcode { private string value; public DutchZipcode(string value) { if (!DutchZipcodeHelper.Validate(value)) { throw new ArgumentException(); } this.value = value; } public string Value { get { return value; } } }  

Comentários

• Então me mostre como o DutchZipcodeHelper deve ser feito?
• @ powder366 Validar é privado método em DutchZipcode

Helper é um apêndice de nome comumente usado.

No entanto , comunica muito pouco sobre o que ele faz. Cada vez que o vi usado, descobri que era um nome abaixo do ideal.

Na verdade, considero que é um cheiro de código que indica mais problemas por baixo.

Exemplo

Suponha que vejamos o nome ” WidgetHelper ” (aqui ” widget ” é um nome substituto para qualquer tipo de funcionalidade programável, e não necessariamente um widget de IU):

 class WidgetHelper: ...  

O que aprendemos com o nome? Sabemos que o objeto ou função faz algum tipo de trabalho secundário ao widget. Em minha experiência, isso pode nem mesmo ser verdade e pode-se excluir ” helper ” do nome e melhorar a comunicação.

Para outra possibilidade, ” WidgetHelper ” poderia estar envolvendo o widget, de modo que o próprio código do widget possa saber nada sobre o ajudante. A implicação é que WidgetHelper neste exemplo de pseudocódigo faz parte da API pública:

 class WidgetHelper: def __init__(self): self.widget = Widget() ...  

Nesse caso, algo como ” WidgetAPI ” seria um nome melhor, porque isso, pelo menos, informa ao usuário sua relação com a classe Widget. Ou talvez excluamos ” Helper ” do nome e renomeamos Widget para algo como WidgetImplementation.

Alternativamente, ele poderia ser agrupado e chamado pelo widget, o que implica que não faz parte da API pública, mas em vez disso, parte dos detalhes de implementação.

 class Widget: def __init__(self): self.widget_helper = WidgetHelper() ...  

Mesmo neste caso, com este pequena quantidade de informações, temos uma melhoria no ” auxiliar. ” Seria mais descritivo chamá-lo de algum nome genérico como ” WidgetImplementation. ”

” Implementação ” pode estar correto, pois a implementação pode fazer muito para dar-lhe um nome mais preciso. Ou pode ser muito vago – fica a critério do nomeador.

Mas, como vimos, o nome, ” auxiliar, ” não ajuda a entender o que está acontecendo no código, a não ser que seja acessório ao objeto principal de interesse. ” Auxiliar, ” pode significar muitos tipos de relacionamentos. Portanto, é muito vago e nebuloso e não é adequado para o propósito de informar ao usuário o que o objeto faz.

Conclusão

Nomear coisas é um dos problemas difíceis da ciência da computação.

O que é desejável em um nome é que ele informe ao usuário o que a coisa nomeada deve fazer.

Mas, em qualquer caso imaginável, seria mais descritivo usar um nome diferente de ” helper ” ou simplesmente remova-o completamente.

Como corolário da minha experiência e desta discussão, a escolha de ” auxiliar ” em um nome também sinaliza baixo esforço ou sofisticação por parte de quem nomeia (corretamente ou não). É, de fato, um cheiro de código.

Não chame nada de ” auxiliar. ”

Na verdade, não é.

” Helper ” é um substantivo coletivo para um grupo de funções.

Um auxiliar é algo que funciona em todo o projeto e faz uma pequena coisa. Muitas vezes, esses caras nem mesmo estão organizados em uma classe, eles apenas estendem a funcionalidade ou os recursos da própria linguagem. Aqui está o que considero um ótimo exemplo de ajudante:

 function linesOf($mls) { return preg_split("/\s*\n\s*/",trim($mls)); }  

Esta função minúscula pode ter um grande impacto em como você organiza seu código (você vai adorar colocar suas listas literais em strings de várias linhas), mas por si só, significa quase nada. É um padrão regex glorificado. Ainda assim, torna seu código muito mais legível quando você diz

 $a = linesOf(" apples bananas cherries ");  

em vez de seu equivalente regex puro.

Então, isso é o que os ajudantes são. Ferramentas minúsculas para trabalhos genéricos, não pertencentes a uma classe específica. Você pode forçá-los em um (linesOf pode ser um método de uma classe de string), mas onde eles realmente pertencem é o namespace global ou uma coleção estática de tais ferramentas.

Regra de polegar: se for útil, mas não parece pertencer a nenhum lugar, é provavelmente um ajudante.

Claro ” esta é uma área cinza, ” mas minha experiência pragmática tem sido que as pessoas inventam ” ajudantes ” quando identificam algum conjunto de código comum útil para elas que usam “Não quero reimplementar. (Alguns idiomas se referem a eles como ” mixins. “)

O problema é que o código comum é tangencialmente relacionada a cada uma das outras classes que pode ” ajudar. ” Em vez de fazer parte de uma hierarquia de classes estrita, apenas ” ajuda ” [todos …] eles. Essa estratégia evita a duplicação do código-fonte, mas apresenta seus perigos.

Minha empresa costumava usar o Base classe / metodologia de classe auxiliar onde cada objeto teria duas classes. Você teria uma classe Person que continha todas as propriedades e definições da classe e uma classe PersonHelper que continha todos os métodos, instruções SQL e Lógica que manipulavam a classe Person. Isso funcionou bem para nós porque todos os nossos aplicativos usam instruções SQL para manipular dados e foi muito fácil localizar e modificar as instruções SQL conforme necessário.

Desde então, mudamos e agora colocamos tudo na classe Person / Base. Paramos de usar a convenção de nomenclatura Helper porque queríamos ter menos arquivos em nossos projetos. Além disso, o comprimento de alguns nomes de classes estava ficando fora de controle. lol.

Não é um ótimo exemplo, mas essa é a ideia.

s = CompanyName.PersonHelper.GetPerson() s = CompanyName.Person.GetPerson() 

Não estou dizendo que usar a convenção de nomenclatura auxiliar é o ideal solução, mas funcionou para nós por alguns anos.

Comentários

• Você não ‘ t explique o porquê.
• Sim, eu ‘ d gosto dessa explicação também.
• @AaronHall Considere isso uma coisa boa que você não entende escolha deles.
• O motivo usual é ” Alguém achou que era uma boa ideia “.