naming - servicio - ¿Cuál es el mejor enfoque para nombrar las clases?
naming traduccion (6)
Citaré algunos pasajes de Implementation Patterns de Kent Beck:
Nombre simple de superclase
"[...] Los nombres deben ser cortos y contundentes. Sin embargo, para hacer que los nombres sean precisos a veces parece requerir varias palabras. Una manera de salir de este dilema es escoger una metáfora fuerte para el cálculo. Con una metáfora en mente, incluso las palabras sueltas traen consigo una rica red de asociaciones, conexiones e implicaciones. Por ejemplo, en el marco de dibujo de HotDraw, mi primer nombre para un objeto en un dibujo era DrawingObject . Ward Cunningham llegó con la metáfora de la tipografía: un dibujo es como una página impresa y diseñada. Los elementos gráficos en una página son figuras, por lo que la clase se convirtió en Figura . En el contexto de la metáfora, Figure es simultáneamente más corta, más rica y más precisa que DrawingObject ".
Nombre de la subclase calificada
"Los nombres de las subclases tienen dos trabajos: necesitan comunicar a qué clase pertenecen y cómo son diferentes. [...] A diferencia de los nombres en las raíces de las jerarquías, los nombres de las subclases no se usan casi con la misma frecuencia en las conversaciones. para que puedan ser expresivos a costa de ser concisos. [...]
Proporcione a las subclases que sirven como raíz de las jerarquías sus propios nombres simples. Por ejemplo, HotDraw tiene un Handle de clase que presenta operaciones de edición de figuras cuando se selecciona una figura. Se llama, simplemente, Handle a pesar de extender Figure . Hay toda una familia de identificadores y, más apropiadamente, tienen nombres como StretchyHandle y TransparencyHandle . Como Handle es la raíz de su propia jerarquía, merece un nombre de superclase simple más que un nombre de subclase calificado.
Otra arruga en el nombramiento de subclases es jerarquías de niveles múltiples. [...] En lugar de anteponer ciegamente los modificadores a la superclase inmediata, piense en el nombre desde la perspectiva del lector. ¿En qué clase necesita saber esta clase? Usa esa superclase como base para el nombre de la subclase ".
Interfaz
Dos estilos de interfaces de nombres dependen de cómo piense en las interfaces. Las interfaces como clases sin implementaciones deben nombrarse como si fueran clases ( nombre de superclase simple , nombre de subclase calificado ). Un problema con este estilo de denominación es que los nombres correctos se agotan antes de llegar a nombrar las clases. Una interfaz llamada File necesita una clase de implementación llamada algo como ActualFile , ConcreteFile o (yuck!) FileImpl (tanto un sufijo como una abreviatura). En general, es importante comunicar si uno está tratando con un objeto concreto o abstracto, ya sea que el objeto abstracto se implemente como una interfaz o una superclase sea menos importante. Diferir la distinción entre interfaces y superclases está> bien respaldado por este estilo de denominación, que te deja en libertad de cambiar de opinión más adelante si eso es necesario.
A veces, nombrar clases concretas simplemente es más importante para la comunicación que ocultar el uso de las interfaces. En este caso, prefija los nombres de la interfaz con "I". Si la interfaz se llama IFile , la clase se puede llamar simplemente Archivo .
Para una discusión más detallada, ¡compre el libro! ¡Vale la pena! :)
Proponer nombres buenos y precisos para las clases es notoriamente difícil. Hecho bien, hace que el código sea más autodocumentado y proporciona un vocabulario para razonar sobre el código en un nivel más alto de abstracción.
Las clases que implementan un patrón de diseño particular pueden recibir un nombre basado en el nombre de patrón conocido (por ejemplo, FooFactory, FooFacade) y las clases que directamente modelan conceptos de dominio pueden tomar sus nombres del dominio del problema, pero ¿qué pasa con otras clases? ¿Hay algo así como el diccionario de sinónimos de un programador al que pueda acudir cuando me falta inspiración y quiero evitar el uso de nombres de clases genéricos (como FooHandler, FooProcessor, FooUtils y FooManager)?
La excelente charla de Josh Bloch sobre el buen diseño de API tiene algunos buenos consejos:
- Las clases deben hacer una cosa y hacerlo bien.
- Si una clase es difícil de nombrar o explicar, probablemente no siga los consejos del punto anterior.
- Un nombre de clase debe comunicar instantáneamente qué clase es.
- Los buenos nombres conducen buenos diseños.
Si su problema es cómo nombrar las clases internas expuestas, tal vez debería consolidarlas en una clase más grande.
Si su problema es nombrar una clase que está haciendo muchas cosas diferentes, debería considerar dividirla en varias clases.
Si ese es un buen consejo para una API pública, entonces no puede perjudicar a ninguna otra clase.
Si su "FooProcessor" realmente procesa foos, entonces no se muestre reacio a darle ese nombre solo porque ya tiene un BarProcessor, BazProcessor, etc. En caso de duda, lo obvio es lo mejor. Los otros desarrolladores que tienen que leer su código pueden no estar usando el mismo diccionario de sinónimos que usted.
Dicho esto, una mayor especificidad no afectaría a este ejemplo en particular. "Proceso" es una palabra bastante amplia. ¿Es realmente un "FooUpdateProcessor" (que podría convertirse en "FooUpdater"), por ejemplo? No tiene que ser demasiado "creativo" con respecto a la denominación, pero si escribió el código probablemente tenga una idea bastante buena de lo que hace y lo que no hace.
Finalmente, recuerde que el nombre de la clase al descubierto no es todo lo que usted y los lectores de su código tienen que seguir: generalmente también hay espacios de nombres en juego. Esos a menudo pueden dar a los lectores suficiente contexto para ver claramente para qué es realmente su clase, incluso si su nombre simple es bastante genérico.
Si tiene un nombre, a veces solo darle un nombre medio sensible con el compromiso de revisarlo más tarde es una buena estrategia.
No digas parálisis. Sí, los nombres son muy importantes pero no son lo suficientemente importantes como para perder grandes cantidades de tiempo. Si no puedes encontrar un buen nombre en 10 minutos, sigue adelante.
Si un buen nombre no viene a la mente, probablemente me preguntaría si hay un problema más profundo: ¿la clase sirve para un buen propósito? Si es así, nombrarlo debería ser bastante sencillo.
Siempre opta por MyClassA, MyClassB: permite una buena ordenación alfa ...
¡Estoy bromenando!
Esta es una buena pregunta, y algo que experimenté no hace mucho tiempo. Estaba reorganizando mi base de código en el trabajo y estaba teniendo problemas de dónde poner qué y cómo llamarlo.
El problema real ?
Tenía clases haciendo demasiado. Si intenta cumplir con el principio de responsabilidad única , todo se combinará mucho mejor. En lugar de una clase de PrintHandler monolítica, podría descomponerlo en PageHandler , PageFormatter (y así sucesivamente) y luego tener una clase de impresora maestra que lo une todo.
En mi reorganización, me llevó tiempo, pero terminé mezclando un montón de código duplicado, obtuve una base de código mucho más lógica y aprendí muchísimo cuando se trata de pensar antes de lanzar un método extra en una clase: D
Sin embargo, no recomendaría poner cosas como nombres de patrones en el nombre de la clase. La interfaz de clases debería hacer eso obvio (como ocultar el constructor para un singleton). No hay nada de malo con el nombre genérico, si la clase tiene un propósito genérico.
¡Buena suerte!