design - sourcemaking - ¿Cuáles son algunos nombres de clase que indicarían la necesidad de refactorizar?
refactoring java (11)
Creo que esta pregunta se debe ver en el panorama más amplio de escoger el nombre correcto para cualquier medio. Cuando mi esposa me pide que saque algo del armario, ¿cómo se supone que voy a saber qué armario quiere decir?
Tal vez los objetos de mi clase sí crean botones, ¿por qué no llamarlo ButtonFactory? Tal vez ese objeto gestiona la vida útil de los archivos temporales, así que vamos a llamarlo TemporaryFileManager.
El problema surge cuando no tienes suficiente información contextual. Esto es especialmente difícil cuando se crean componentes reutilizables: mi TemporaryFileManager puede ser una subclase de una clase Manager genérica, y mi ButtonFactory puede ser un caso especial de WidgetFactory.
Mientras el nombre describa lo que hace la cosa en su contexto , estoy bien. Y de eso trata el artículo mencionado.
Encontré algunos artículos como este , que sugieren que algunas palabras nunca deben usarse como parte de un nombre de clase. Cuando una clase tiene una de esas palabras en el nombre, significa que el código debe ser refactorizado o rediseñado.
Ejemplo:
Gerente
Motivo: dado que casi todas las clases "administran" algo y el significado de "Gerente" es muy amplio, las personas pueden poner muchas responsabilidades en una clase de "Gerente" al mismo tiempo que pueden reclamar que la clase "solo tiene una cosa". Como resultado, nombrar una clase con "Administrador" no dice mucho sobre lo que la clase realmente hace. El artículo mencionado anteriormente, "Nombrar clases de Java sin un ''Administrador''" , mostró este punto:
Por ejemplo, tome una clase llamada "UrlManager": no puede decir si agrupa las URL, manipula las URL o si audita el uso de ellas. Todo lo que el nombre te dice es que esta no es una URL, pero de alguna manera funciona con ellas. Por otro lado, el nombre "UrlBuilder" ofrece una imagen mucho mejor de lo que hace la clase.
Otro ejemplo:
Ayudante
Motivo: un nombre de clase como "ThreadHelper" hace que las personas se pregunten por qué es necesario y por qué no puede formar parte de la clase "Thread". ¿Es en realidad un adaptador o un decorador? Si es así, nómbrelo de esa manera. ¿La clase "Thread" ya asume demasiada responsabilidad? Si es así, refactoriza y dale a la nueva clase un nombre significativo. "Ayuda" no dice nada sobre lo que está haciendo o cómo está ayudando.
¿Qué otras palabras en un nombre de clase indican la necesidad de refactorizar o rediseñar y deben evitarse? ¿Por qué?
Editar: Creo que esas palabras se usan mucho desde
- generalmente tienen un amplio significado
- pueden caber en casi todos los contextos
- detienen a los diseñadores pensando en mejores diseños o nombres
- la gente cree que está bien usarlos
El libro Código de limpieza enumeró más, pero no se dieron razones:
Evite palabras como Administrador, Procesador, Datos o Información en el nombre de una clase.
Sería genial si alguien pudiera proporcionar razones posibles para ellos.
Preguntas relacionadas:
Cualquier cosa que pueda anular las clases estándar (por ejemplo: Comparator , Iterable & c. En Java), a menos que comprenda y específicamente intente causar este tipo de comportamiento.
La inclusión de malas ideas podría tomar un tiempo, solo pensar en una gran cantidad de nombres malos: lector, escritor, fábrica, artículo, temporizador, receptor, remitente, etc., etc.
Básicamente, evite los nombres que no le dan contexto para lo que es la clase o su papel en el panorama general. No tiene que ser tan exagerado como IHelpToSendXMLDataToTheServer , pero posiblemente XMLBroadcastUtil no sería terrible. Algunas personas llegan incluso a agregar un prefijo particular, un sufijo a los nombres de las clases para designar con qué módulo trabaja. Sin embargo, yo diría que esto es parte del rol del espacio de nombres / paquete.
Modelo de plantilla abstracto Objeto de fábrica
Todos estos son realmente genéricos, y algunos de ellos podrían ser obvios a partir de la definición de la clase. Otros obviamente se notan mejor en un poco de documentación (la referencia fácil de esto es una de las razones para agradar el reafilamiento)
Esta
eso siempre es una mala llamada.
1) Cualquier cosa menos de 3 caracteres realmente me pone de los nervios. Realmente duele la legibilidad, ya que 3 caracteres al menos generalmente te da al menos una vocal. Personalmente, trato de usar al menos 5 caracteres.
2) Una de las cosas que más me molestan es el nombre de la clase que termina en la clase (por ejemplo, personClass o buttonClass), ya que te quita el hecho de que estás creando un objeto, no una clase. Al hacer instancias de una clase similar, encuentro que está bien (por ejemplo, blueButton, redLabel), ya que es más fácil de leer, pero la cosa de la clase puede ser realmente molesta.
Artículos ( The , A , An )
Pronombres y nombres ( My , Their , John )
Números, excepto las versiones de especificaciones ( 2 , 3 , 5000 )
Adjetivos mullidos ( Fast , Smart , Good , Better )
Idioma extranjero que la mayoría del equipo no comprende (Ελληνικά)
Cualquier nombre que contenga caracteres que no sean 7bit ascii.
Realmente no puedo entender o incluso editar caracteres Hindi.
class हिन्दी:হিন্দী ঠার
{
// argh..
}
Mis identificadores menos favoritos en general son:
- Palabras mal escritas. GEM tenía una paleta deletreada como "pallete" en todas sus llamadas API. Enloquecedor.
- Identificadores donde no puedo decir si un personaje es un 1 o un l, o un 0 o un O.
- Las siete palabras sucias de George Carlin.
Todo sugerido en Cómo escribir un código no permanente .