naming-conventions - name - snake case naming

Nombramiento de convenciones y estructura para clases de utilidad y métodos. (2)

¿Tiene alguna entrada sobre cómo organizar y nombrar las clases de utilidad?

Cada vez que ejecuto alguna duplicación de código, podría ser solo un par de líneas de código, las muevo a una clase de utilidad.

Después de un tiempo, tiendo a obtener muchas clases estáticas pequeñas, generalmente con un solo método, que normalmente pongo en un espacio de nombres de utility que se llena de clases.

Ejemplos:

ParseCommaSeparatedIntegersFromString( string ) CreateCommaSeparatedStringFromIntegers( int[] ) CleanHtmlTags( string ) GetListOfIdsFromCollectionOfX( CollectionX ) CompressByteData( byte[] )

Por lo general, las convenciones de nomenclatura le dicen que nombre a su clase como un Sustantivo. A menudo termino con muchas clases como HtmlHelper , CompressHelper pero no son muy informativas. También he intentado ser realmente específico como HtmlTagCleaner , que generalmente termina con una clase por método de utilidad.

¿Tiene alguna idea sobre cómo nombrar y agrupar estos métodos de ayuda?

Creo que hay un continuo de complejidad, por lo tanto las organizaciones correspondientes . A continuación se incluyen algunos ejemplos, elija según la complejidad de su proyecto y sus utilidades, y adáptese a otras restricciones:

Una clase (llamada Helper), con algunos métodos.
Un paquete (llamado ayudante), con algunas clases (llamado XXXHelper), cada clase con algunos métodos. Alternativamente, las clases se pueden dividir en varios paquetes que no sean de ayuda si encajan.
Un proyecto (llamado ayudante), con unos pocos paquetes (llamado XXX), cada paquete con ... Alternativamente, los paquetes se pueden dividir en varios paquetes que no son de ayuda si caben.
Varios proyectos de ayuda (divididos por nivel, por biblioteca en uso o de otra manera) ...

En cada nivel de agrupación (paquete, clase):

La parte común del significado es el nombre del nombre de la agrupación.
Los códigos internos ya no necesitan ese significado (por lo que su nombre es más corto, está más enfocado y no necesita abreviaturas, usa nombres completos).

Para proyectos, generalmente repito el significado común en un nombre de superpaquete. Aunque en teoría no es mi opción preferida, no veo en mi IDE (Eclipse) desde qué proyecto se importa una clase, así que necesito que se repita la información. El proyecto en realidad solo se usa como:

una unidad de envío: algunos entregables o productos tendrán el frasco, los que no lo necesiten no lo harán),
para expresar dependencias: por ejemplo, un proyecto empresarial no tiene dependencia en los ayudantes de nivel web; habiendo expresado que en las dependencias de los proyectos, hicimos una mejora en la complejidad aparente, bueno para nosotros; o al encontrar tal dependencia, sabemos que algo está mal y comenzamos a investigar ...; También, al reducir las dependencias, podemos acelerar la compilación y la construcción ...
para categorizar el código, para encontrarlo más rápido: solo cuando es enorme, estoy hablando de miles de clases en el proyecto

Tenga en cuenta que todo lo anterior se aplica también a los métodos dinámicos, no solo a los estáticos. En realidad son nuestras buenas prácticas para todo nuestro código.

Ahora que intenté responder a su pregunta (aunque de manera amplia), permítame agregar otro pensamiento
(Sé que no lo pediste).

Los métodos estáticos (excepto los que utilizan miembros de clase estática) funcionan sin contexto, todos los datos deben pasarse como parámetros. Todos sabemos que, en el código OO, esta no es la forma preferida. En teoría, deberíamos buscar el objeto más relevante para el método y mover ese método sobre ese objeto. Recuerde que el uso compartido de códigos no tiene que ser estático , solo tiene que ser público (o visible).

Ejemplos de dónde mover un método estático:

Si solo hay un parámetro, a ese parámetro.
Si hay varios parámetros, elija entre mover el método en:
- el parámetro que más se usa: el que utiliza varios campos o métodos, o usado por condicionales (idealmente, algunas condiciones serían eliminadas por el reemplazo de subclases) ...
- Un objeto existente que ya tiene buen acceso a varios de los parámetros.
- construir una nueva clase para esa necesidad

Aunque este método de movimiento pueda parecer para OO-purista, encontramos que esto realmente nos ayuda a largo plazo (y resulta invaluable cuando queremos subclasificarlo, para alterar un algoritmo). Eclipse mueve un método en menos de un minuto (con todas las verificaciones), y ganamos mucho más de un minuto cuando buscamos algún código, o cuando no codificamos nuevamente un método que ya estaba codificado.

Limitaciones: algunas clases no se pueden extender, generalmente porque están fuera de control (JDK, bibliotecas ...). Creo que esta es la verdadera justificación del ayudante, cuando necesitas poner un método en una clase que no puedes cambiar .
Nuestra buena práctica es nombrar al ayudante con el nombre de la clase a extender, con el sufijo Helper. (StringHelper, DateHelper). Esta estrecha coincidencia entre la clase en la que nos gustaría que estuviera el código y el Ayudante nos ayuda a encontrar ese método en unos pocos segundos, incluso sin saber si alguien más en nuestro proyecto escribió ese método o no.

Helper sufijo Helper es una buena convención , ya que se usa en otros idiomas (al menos en Java, los rieles IIRC lo usan).

La intención de su ayudante debe ser transportada por el nombre del método y usar la clase solo como marcador de posición. Por ejemplo, ParseCommaSeparatedIntegersFromString es un mal nombre por un par de razones:

demasiado largo, de verdad
es redundante, en un lenguaje estático puede eliminar el sufijo FromString ya que se deduce de la firma

Qué piensa usted acerca de:

CSVHelper.parse(String) CSVHelper.create(int[]) HTMLHelper.clean(String) ...