class - ¿Es la palabra "Ayudante" en el nombre de una clase un olor a código?

language-agnostic helper

Question

Parece que estamos abstrayendo mucha lógica de las páginas web y creando clases de "ayuda". Lamentablemente, estas clases suenan igual, por ejemplo

ADHelper, (Active Directory) AuthenicationHelper, SharePointHelper

¿Tienen otras personas una gran cantidad de clases con esta convención de nombres?

Answer 1

Como siempre, depende del contexto.

Cuando trabajas con tu propia API definitivamente lo consideraría un olor a código, porque FooHelper indica que opera en Foo , pero el comportamiento probablemente pertenecería directamente a la clase Foo .

Sin embargo, cuando trabajas con API existentes (como tipos en BCL), no puedes cambiar la implementación, por lo que los métodos de extensión se convierten en una de las formas de solucionar las deficiencias en la API original. Puede elegir nombrar esas clases FooHelper tan bien como FooExtension . Es igualmente maloliente (o no).

Answer 2

Depende del contenido real de las clases.

Si hay una gran cantidad de reglas reales de negocios / lógica comercial en las clases de ayuda, entonces diría que sí.

Si las clases son realmente solo ayudantes que se pueden usar en otras aplicaciones empresariales (reutilización en el sentido absoluto de la palabra, no copiar y luego personalizar), entonces diría que los ayudantes no son un olor a código.

Answer 3

Diría que califica como un olor a código, pero recuerda que un olor a código no necesariamente significa un problema. Es algo que debes considerar y luego decidir si está bien.

Habiendo dicho eso, personalmente encuentro que un nombre como ese agrega muy poco valor y dado que es tan genérico, el tipo puede convertirse fácilmente en un grupo de métodos de utilidad no relacionados. Es decir, una clase auxiliar puede convertirse en una clase grande, que es uno de los olores comunes del código .

Si es posible, sugiero encontrar un nombre de tipo que describa con más detalle lo que hacen los métodos. Por supuesto, esto puede generar clases de ayuda adicionales, pero siempre que sus nombres sean útiles, no me importan los números.

Hace algún tiempo encontré una clase llamada XmlHelper durante una revisión del código. Tenía una serie de métodos que obviamente todos tenían que ver con Xml. Sin embargo, no estaba claro por el nombre de tipo qué tenían los métodos en común (aparte de estar relacionado con Xml). Resultó que algunos de los métodos formateaban Xml y otros analizaban Xml. Entonces, la clase IMO debería haberse dividido en dos o más partes con nombres más específicos.

Answer 4

En muchos casos, uso clases que terminan en Helper para clases estáticas que contienen métodos de extensión. No me parece mal. No puedes ponerlos en una clase no estática, y la clase en sí no importa, por lo que Helper está bien, creo. Los usuarios de dicha clase no verán el nombre de la clase de todos modos.

.NET Framework hace esto también (por ejemplo, en la clase LogicalTreeHelper de WPF, que solo tiene unos pocos métodos estáticos (sin extensión)).

Pregúntese si el código sería mejor si el código de su clase auxiliar se refactorizara a clases "reales", es decir, objetos que se ajusten a su jerarquía de clases. El código tiene que estar en alguna parte, y si no puedes distinguir una clase / objeto a la que realmente pertenece, como funciones simples de ayuda (de ahí "Ayuda"), deberías estar bien.

Answer 5

Es un punto interesante, si una palabra se convierte en ''repetitivo'' en los nombres, entonces es probable que sea un poco confuso, si no un verdadero olor. Tal vez el uso de una carpeta ''Ayuda'' y luego permitir que aparezca en el espacio de nombres, ¿se mantiene sin abusar de la palabra?

Application.Helper.SharePoint
Application.Helper.Authentication

y así

Answer 6

No diría que es un olor a código. En ASP.NET MVC es bastante común.