Práctica recomendada para nombrar subclases

Question

A menudo me encuentro en una situación en la que tengo un concepto representado por una interfaz o clase, y luego tengo una serie de subclases/subinterfaces que lo amplían.

Por ejemplo: Un genérico "DoiGraphNode" A "DoiGraphNode" que representa un recurso A "DoiGraphNode" que representa un recurso Java A "DoiGraphNode" con una ruta asociada, etc., etc.

I puede pensar en tres convenciones de nombres, y agradecería comentarios sobre cómo elegir.

---

Opción 1: Comience siempre con el nombre del concepto.

Por lo tanto: DoiGraphNode, DoiGraphNodeResource, DoiGraphNodeJavaResource, DoiGraphNodeWithPath, etc.

Pro: Es muy claro lo que estoy tratando, es fácil ver todas las opciones que tengo

En contra: No muy ¿natural? ¿Todo se ve igual?

---

Opción 2: Poner las cosas especiales al principio.

Por lo tanto: DoiGraphNode, ResourceDoiGraphNode, JavaResourceDoiGraphNode, PathBaseDoiGraphNode, etc., etc.

Pro: Es muy claro cuando lo veo en el código

Con: encontrar que podría ser difícil, especialmente si no me acuerdo el nombre, la falta de coherencia visual

---

Opción 3: Colocar el material especial y eliminar parte del texto redundante

Por lo tanto: DoiGraphNode, ResourceNode, JavaResourceNode, GraphNodeWithPath

Pro: No hay mucho que escribir y leer Con: Parece que cr * p, muy inconsistente, puede entrar en conflicto con otros nombres

Answer 1

Nombre ellos por lo que son.

Si nombrarlos es difícil o ambiguo, a menudo es una señal de que la Clase está haciendo demasiado (Principio de responsabilidad única).

Para evitar conflictos de nombres, elija sus espacios de nombres de forma adecuada.

Personalmente, me gustaría usar 3

Answer 2

Use lo que quiera, es algo subjetivo Lo importante es aclarar qué representa cada clase, y los nombres deben ser tales que las relaciones de herencia tengan sentido. En realidad, no creo que sea tan importante codificar las relaciones en los nombres; para eso sirve la documentación (y si sus nombres son apropiados para los objetos, las personas deberían poder adivinar qué hereda de qué).

Por lo que vale la pena, que suelen utilizar la opción 3, y desde mi experiencia mirando opción de código de otras personas 2 es probablemente más frecuente que la opción 1.

Answer 3

Opción tres más la consecuencia lógica del concepto de herencia. Ya que está especializando la interfaz o clase, el nombre debe mostrar que ya no está utilizando la implementación base (si existe).

Hay una multitud de herramientas para ver de qué hereda una clase, por lo que un nombre conciso que indique la función real de la clase irá más allá de tratar de incluir demasiada información de tipo en el nombre.

Answer 4

Puede encontrar alguna guía en un documento de estándares de codificación, por ejemplo, está el documento IDesign para C# here.

Personalmente, prefiero la opción 2. Esta es generalmente la forma en que .NET Framework nombra sus objetos. Por ejemplo, mira las clases de atributos. Todos terminan en Attribute (TestMethodAttribute). Lo mismo ocurre con EventHandlers: OnClickEventHandler es un nombre recomendado para un controlador de eventos que maneja el evento Click.

Normalmente trato de seguir esto en el diseño de mi propio código e interfaces. Por lo tanto, un IUnitWriter produce un StringUnitWriter y un DataTableUnitWriter. De esta manera, siempre sé cuál es su clase base y se lee de forma más natural. El código de auto-documentación es el objetivo final para todos los desarrolladores ágiles, ¡así que parece funcionar bien para mí!

Answer 5

Por lo general, llamo similar a la opción 1, especialmente cuando las clases se usarán polimóficamente. Mi razonamiento es que la información más importante se enumera primero. (es decir, el hecho de que la subclase es básicamente lo que es el antepasado, con (normalmente) extensiones 'agregadas'). También me gusta esta opción porque al ordenar listas de nombres de clase, , las clases relacionadas se enumerarán juntas. Es decir Por lo general, nombre la unidad de traducción (nombre de archivo) igual que el nombre de la clase, por lo que los archivos de clase relacionados se enumerarán de forma conjunta. De manera similar, esto es útil con la búsqueda incremental.

Aunque solía utilizar la opción 2 anteriormente en mi carrera de programación, la evito ahora porque, como dices, es "inconsistente" y no parece muy ortogonal.

A menudo uso la opción 3 cuando la subclase proporciona una extensión o especificación sustancial, o si los nombres son bastante largos. Por ejemplo, mi archivo de clases de nombre de sistema se derivan de cadena sino que se extienden en gran medida la clase String y tienen una significativamente diferente uso/significado:

Directory_entry_name derivado de cadena Agrega una amplia funcionalidad. File_name derivado de Directory_entry_name tiene funciones bastante especializadas. Directory_name derivado de Directory_entry_name también tiene funciones bastante especializadas.

También junto con la opción 1, generalmente uso un nombre no calificado para una clase de interfaz. Por ejemplo I podría tener una cadena interence clase:

• Texto (una interfaz)
• Text_abstract (resumen (base) clase generalización)
• Text_ASCII (clase concreta específico para ASCII codificación)
• Text_unicode (clase concreta específica para codificación Unicode)

Me gusta más que la interfaz y la clase base abstracta aparezcan automáticamente primero en la lista ordenada.