2009-03-23 9 views
14

Durante mi último proyecto noté, que es muy conveniente, incluir nombres de patrones de diseño en nombres de clase. Por ejemplo:Cuándo incluir un nombre de patrón de diseño en el nombre de clase?

  • ContextLazyFactory
  • RunOnceMediator
  • ThirdPartyMediator
  • MyProjectCliFacade
  • BinaryGate

Esto hace que el proyecto fácil de leer. El beneficio adicional es que no usará sus propios nombres como "RunOnceManager", "ContextDelayedConstruction", "ThirdPartyInterface", etc. que pueden tener un significado nítido solo para el autor. Por otro lado, no me gustaría ver clases como vector_container en el STL. ¿Cómo crees que?

Mi visión actual sobre este tema es: las clases que son nodos importantes en la jerarquía de clases deben tener su patrón de diseño en su nombre, para enfatizar la estructura jerárquica y facilitar la lectura del proyecto.

Respuesta

20

Parece natural para mí en muchos casos:

  • Los patrones de diseño se nombran a explicar lo que hacen
  • Las clases se nombran a explicar lo que hacen

Cuando la forma más sencilla de explicar el propósito de una clase es en términos de patrones de diseño, ¿por qué no usarlo?

Por otro lado, cuando el patrón de diseño es en su mayoría incidental, entonces excluirlo. Por ejemplo, una clase puede ser un singleton, pero ese no es su objetivo principal en la vida, por lo que no esperaría ver "Singleton" en el nombre. Compare eso con una fábrica cuyo objetivo principal es ser una fábrica para otros objetos: "FooFactory" tiene mucho sentido.

+1

Downvoters: proporcione un comentario para explicar por qué no está de acuerdo con una respuesta cuando rechaza. –

+0

+1 completamente de acuerdo. – eglasius

+0

@Jon en este caso, creo que es justo asumir que los detractores se sienten fuertes al ponerlo en el nombre o al no ponerlo en absoluto, en cualquier caso, no creo que se pueda hacer mucho con esa información (aparte de entrar) una larga discusión al respecto). – eglasius

0

Estoy de acuerdo contigo. Lo único que agregaría (lo cual es evidente) es asegurarnos de que el nombre del patrón dentro del nombre de la clase use el patrón real empleado.

¡Una vez vi una clase llamada XxxxFactory (o algo así) y no tenía ninguna semejanza con un patrón de fábrica en absoluto!

0

También uso el nombre del patrón de diseño en los nombres de las clases para aumentar la legibilidad y facilitar su comprensión a otras personas.

Vectors significa que ya tengo una colección, así que no es necesario _collection. El contenedor Btw no es un patrón de diseño.

0

Si el nombre resultante es lo suficientemente claro, adelante y úselo.

Pero puede haber circunstancias en las que el nombre resultante sea torpe o vago. En ese caso, use el nombre más apropiado.

1

Creo que el uso de patrones de diseño en los nombres es una gran idea .Por ejemplo, en uno de mis juegos que tengo:

GameLevelAbstract 
InGameArea 
MainMenu 

Las otras dos clases (InGameArea y MainMenu) subclase GameLevelAbstract e implementar es métodos virtuales puros. Puedo ver en mi fuente que esa clase es abstracta e inmediatamente sé que es o no lo que estoy buscando.

Otro ejemplo es mi fachada gráficos:

GraphicsFacade 
OpenGLGraphics 
DirectXGraphics 

exactamente la misma configuración, ya que tenía el anterior, excepto que se trata de gráficos.

Encuentro que usar el patrón de diseño en el nombre es útil e informativo cuando estoy buscando una clase. Creo que algunas cosas no deberían usarse en el nombre como Singleton, sin embargo, Flyweight, Factory o Facade son ejemplos de nombres de diseño que creo que encajan bien en el nombre de una clase que implementa esos patrones.

Creo que si utiliza buenos nombres de clase que ayudan al programador a obtener una buena idea de lo que hace su clase de un vistazo es algo bueno.

No creo que decir algo sea una estructura de datos o un algoritmo es algo bueno en la mayoría de los casos. "LinkedListDataStructure" o "BubbleSortAortAlgorithm" no agregan nada a la comprensión del programador de la clase, ya que "LinkedList" es obvio en su función.

+0

+1 También me gusta poner "abstract" en el nombre de clase para las clases abstractas. La convención de nomenclatura .NET estándar sería "MyClassBase", pero preferiría "AbstractMyClass" – MattDavey

+0

* "LinkedListDataStructure" o "BubbleSortAlgorithm" no agregan nada a la comprensión del programador. * Totalmente de acuerdo con esto también. El nombre de la clase es parte de su interfaz, y la interfaz no debe publicitar detalles de implementación como este ... Lástima que no puedo +2;) – MattDavey

+1

No me gusta 'Abstracto' en los nombres de las clases base porque cuando ver que 'X' se deriva de' Y', creo que 'X' es un _type_ de' Y' (por ejemplo, un 'Perro' es un tipo de' Animal', no 'AbstractoAnimal'). Aunque una variable de tipo 'AbstractY' es una referencia abstracta, no apunta a algo que sea abstracto. –

0

Existe al menos un inconveniente: si, por algún motivo, la clase no utiliza el patrón después de una refactorización, debe cambiarle el nombre o tener una clase con un nombre incorrecto.

+1

De acuerdo, pero un patrón de diseño indicaría el comportamiento de un objeto. Si después de refactorizar el objeto no se comporta de forma remota de la misma manera, tal vez debería haber sido una nueva clase en su lugar ... – MattDavey

0

Es realmente bueno agregar nombres de patrones de diseño como nombre de clase. Lo que hace que el código sea más fácil de entender. Los nombres de las clases deberían ser significativos y deberían reflejar la funcionalidad de la clase. Cuando uno agrega el nombre del patrón en el nombre de la clase, agrega más legibilidad, ya que también refleja la técnica que se utilizó para diseñar la clase. Prefiero este tipo de nombre de clase.

Cuestiones relacionadas