¿Qué es un ayudante? ¿Es un patrón de diseño? ¿Es un algoritmo?

Una clase Helper es un olor de código menos conocido en el que un codificador ha identificado algunas operaciones misceláneas y de uso común y ha intentado hacerlas reutilizables agrupándolas juntos en una agrupación antinatural. Los desarrolladores sucesivos han entrado en el proyecto y no se han dado cuenta de que existe la clase de ayuda y, en consecuencia, han reescrito las mismas operaciones comunes, o incluso han creado más clases de ayuda.

Pero en serio, el principal problema con las clases de ayuda es que normalmente son operaciones que actúan sobre una clase específica, lo que obviamente significa en términos OO que están sufriendo un caso agudo de Feature Envy . Esta falla al empaquetar el comportamiento con los datos sobre los que actúa es la razón por la cual los desarrolladores a menudo (en mi experiencia) no lo encuentran.

Además de esto, como ya ha identificado, SomethingSomethingHelper es en realidad un nombre terrible . No es descriptivo y no le da una idea real de qué tipo de operaciones hace la clase (¿ayuda?), Lo que también significa que no es obvio al agregar nuevos comportamientos si pertenecen a la clase Helper o no. organice esas clases siguiendo las líneas de comportamiento relacionado que se agrupan lógicamente, y luego cambie el nombre de las nuevas clases para reflejar lo que hace.

Comentarios

• Pretty asegúrese de que SomethingSomethingHelper no sea el nombre real de la clase. Si es ‘ un olor a código o no dependerá de cuán específico la clase auxiliar es, ya que las clases auxiliares como Math no son un olor de código en absoluto.
• @RobertHarvey – Enh, la mayoría de las que ‘ vimos que han han sido nombrados SomethingSomethingHelper. Demonios, yo ‘ estoy mirando una clase en este momento llamada HelperMethods en el espacio de nombres <company>.Helpers. Para mí, un está en el mismo depósito que *Manager.
• @Telastyn: Quizás ‘ Es una experiencia, entonces. ‘ he examinado las clases auxiliares en mi proyecto actual (hay varias), y todas tienen nombres significativos. Hay ‘ solo uno que ‘ tiene el sufijo Helper, y creo que ‘ s para eliminar la ambigüedad de una clase en .NET Framework que tenga el mismo nombre. Yo ‘ consideraría *Helper aceptable si * fuera algo significativo. HelperMethods es solo una falla de imaginación; debería haber al menos grupos conceptuales específicos.
• @RobertHarvey: ‘ probablemente tengas razón. Toda mi carrera en el uso de lenguajes modernos ha consistido en limpiar restos de trenes.
• Hay un subconjunto de estos, llamado » funciones auxiliares «, que son realmente útiles y un buen patrón.Por ejemplo, un conjunto común de líneas que de otro modo tendrían que repetirse dentro de una función; un ejemplo de dónde aparecen es cuando necesita un bucle do..while en Python, que el lenguaje no admite ‘ t (consulte el segundo ejemplo aquí ). Otra sería una estructura if / elif /…/ else, pero es necesario repetir un caso en la parte superior e inferior. Sin embargo, si es posible, deben hacerse locales para esa función y, por lo general, no deben llamarse » helper «.

Un ayudante es una clase o método adicional inofensivo, siempre que complemente un componente externo. Cuando hace lo contrario, indica un mal diseño porque el código ha sido excluido de su autoridad, si es que hay alguna autoridad.

Aquí hay un ejemplo de un ayudante inofensivo, yo uso un método llamado FindRep que cuenta el número de ceros a la izquierda.

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

El método auxiliar es muy simple, pero muy inconveniente de copiar y pegar y el marco no proporciona ninguna solución.

 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; }  

Y aquí hay un ejemplo de un mal ayudante:

 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; } } }  

Comentarios

• Entonces, muéstrame cómo se debe hacer DutchZipcodeHelper?
• @ powder366 Validate is a private método en DutchZipcode

Helper es un apéndice de nombre de uso común.

Sin embargo , comunica muy poco sobre lo que hace. Cada vez que lo he visto usar, he encontrado que es un nombre subóptimo.

De hecho, considero que es un olor a código que indica más problemas debajo.

Ejemplo

Supongamos que vemos el nombre » WidgetHelper » (aquí » widget » es un nombre sustituto para cualquier tipo de funcionalidad programable, y no necesariamente un widget de interfaz de usuario):

 class WidgetHelper: ...  

¿Qué aprendemos del nombre? Sabemos que el objeto o función realiza algún tipo de trabajo secundario al widget. Según mi experiencia, es posible que esto ni siquiera sea cierto, y uno podría eliminar » helper » del nombre y mejorar la comunicación.

Para otra posibilidad, » WidgetHelper » podría estar envolviendo el widget, de modo que el código del mismo pueda saber nada sobre el ayudante. La implicación es que WidgetHelper en este ejemplo de pseudocódigo es parte de la API pública:

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

En este caso, algo como » WidgetAPI » sería un nombre mejor, porque eso, al menos, informa al usuario su relación con la clase Widget. O quizás eliminamos » Helper » del nombre y, además, cambiamos el nombre de Widget a algo como WidgetImplementation.

Alternativamente, el widget podría envolverlo y llamarlo, lo que implica que no forma parte de la API pública, pero más bien parte de los detalles de implementación.

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

Incluso en este caso, con esto una pequeña cantidad de información tenemos una mejora en » helper. » Sería más descriptivo llamarlo con un nombre genérico como » Implementación de widgets. »

» Implementación » puede ser correcto ya que la implementación puede hacer demasiado para darle un nombre más preciso. O puede ser demasiado vago, esto queda a discreción del nombre.

Pero como hemos visto, el nombre, » helper, » no ayuda a comprender lo que está sucediendo en el código, salvo que sea auxiliar del objeto principal de interés. » Helper, » podría significar muchos tipos de relaciones. Por lo tanto, es demasiado vago y nebuloso, y no es adecuado para informar al usuario lo que hace el objeto.

Conclusión

Nombrar cosas es uno de los problemas difíciles en la informática.

Lo deseable en un nombre es que informe al usuario lo que se supone que debe hacer la cosa nombrada.

Pero en cualquier caso imaginable, sería más descriptivo usar un nombre que no sea » helper » o simplemente eliminarlo por completo.

Como corolario de mi experiencia y esta discusión, la elección de » helper » en un nombre también indica poco esfuerzo o sofisticación por parte del nombrador (correctamente o no). De hecho, es un olor a código.

Por favor, no llame a nada un » helper. »

En realidad, no es ninguno.

» Helper » es un sustantivo colectivo para un grupo de funciones.

Un ayudante es algo que funciona en todo el proyecto y hace algo pequeño. Estos chicos a menudo ni siquiera están organizados en una clase, simplemente amplían la funcionalidad o las capacidades del lenguaje en sí. Aquí está lo que considero un muy buen ejemplo de ayudante:

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

Esta pequeña función puede tener un gran impacto en la forma en que organiza su código (le encantará poner sus listas literales en cadenas de varias líneas) pero en sí mismo, no significa casi nada. Es un patrón de expresiones regulares glorificado. Aún así, hace que su código sea mucho más legible cuando dice

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

en lugar de su equivalente de expresión regular pura.

Así que eso es lo que son los ayudantes. Pequeñas herramientas para trabajos genéricos, que no pertenecen a una clase específica. Puede forzarlos en uno (linesOf podría ser un método de una clase de cadena) pero donde realmente pertenecen es el espacio de nombres global o una colección estática de tales herramientas.

Regla de pulgar: si es útil pero no parece pertenecer a ninguna parte, probablemente sea una ayuda.

Por supuesto, » esta es un área gris, » pero Mi experiencia pragmática ha sido que las personas inventan » ayudantes » cuando han identificado un conjunto de códigos comunes útiles para ellos «No quiero volver a implementar. (Algunos lenguajes se refieren a ellos como » mixins. «)

El problema es que el código común es tangencialmente relacionado con cada una de las otras clases que podría » ayudar. » En lugar de ser parte de una jerarquía de clases estricta, simplemente » ayuda a » [a todos …]. Esta estrategia evita la duplicación del código fuente, pero no está exenta de peligros.

Mi empresa solía utilizar Base Metodología class / Helper class donde cada objeto tendría dos clases. Tendría una clase Person que contuviera todas las propiedades y definiciones de la clase y una clase PersonHelper que contuviera todos los métodos, declaraciones SQL y Logic que manipularan la clase Person. Esto funcionó bien para nosotros porque todas nuestras aplicaciones usan sentencias SQL para manipular datos y fue muy fácil para nosotros encontrar y modificar las sentencias SQL según sea necesario.

Desde entonces hemos avanzado y ahora ponemos todo en la clase Person / Base. Dejamos de usar la convención de nomenclatura de Helper porque queríamos tener menos archivos en nuestros proyectos. Además, la longitud de algunos de los nombres de las clases se estaba descontrolando. jajaja.

No es un gran ejemplo, pero entiendes la idea.

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

No estoy diciendo que usar la convención de nomenclatura de ayudantes sea perfecto solución, pero funcionó para nosotros durante algunos años.

Comentarios

• No ‘ t explique por qué.
• Sí, ‘ también me gustaría esa explicación.
• @AaronHall Considérelo algo bueno que no comprenda su elección.
• La razón habitual es » Alguien pensó que era una buena idea «.