debería nombrar todas mis clases abstractas AbstractFoo

Question

¿Es una buena práctica asegurarse de que todas las clases abstractas tengan nombres con el prefijo "Resumen"?

Answer 1

Puede pero no tiendo a hacerlo porque es un detalle de implementación.

No me gusta agregar información detallada de implementación en los nombres de tipos e identificadores ya que ese tipo de información puede cambiar en el futuro. En mi opinión, es mejor nombrar las cosas como son, no cómo se implementan.

Answer 2

Eso depende de sus convenciones de codificación.

También puede llamarlos FooBase, o simplemente Foo si aún no tiene una interfaz Foo.

Answer 3

Si considera cómo es en .NET framework, no. Tomemos como ejemplo la clase Stream abstracta. Nada en el nombre de la clase indica que, de hecho, es abstracto.

Answer 4

Encuentro útil nombrar las clases de esta manera. Envía un mensaje de que están destinados a ser subclasificados; no instanciado; contiene el código común a las subclases, etc.

No siempre es necesario. La mayoría de los programadores probablemente identifiquen "Forma" como una clase abstracta y "Cuadrado", "Círculo", etc. como concreto. Pero si no está claro de inmediato, es una pista útil.

También debe guiarse por las convenciones de programación locales y las guías de estilo.

Answer 5

Creo que depende en parte de cómo va a utilizar la clase. Si solo está destinado para uso interno al obligar a las clases derivadas a ajustarse a una interfaz, entonces agregar Abstract antes podría no ser una mala idea. Sin embargo, si está proporcionando una fábrica de Foo que proporcionará instancias de Foo que son realmente SpecializedFoo1 o SpecializedFoo2, parece incómodo devolver instancias de AbstractFoo.

Answer 6

Creo que esta convención de nomenclatura se acaba de utilizar porque es difícil encontrar otro buen nombre. Si ya tiene una interfaz llamada "Lista", ¿cómo nombraría la clase "AbstractList"? Se trata más de evitar los conflictos de nombres y luego contar los detalles de la implementación.

Answer 7

Un poco difícil de explicar, pero solo lo uso para evitar copiar/pegar el mismo código en clases funcionales y no en algo como objetos de dominio.

• AbstractServiceTestCase -> El prefijo Resumen parece útil
• AbstractAnimal -> parece raro e inútil

Usted debe decidir por sí mismo por supuesto, siempre y cuando se sigue la misma convención en todo el proyecto .

Answer 8

Las respuestas hasta ahora son muy útiles y muestran una extensión responsable de la práctica. Tiendo a aceptar que los nombres no deberían indicar la implementación (Foo podría ser una clase abstracta que luego se movió a una interfaz). Sin embargo, es útil para mí cuando codigo tener pistas visuales que necesito proporcionar métodos para las clases derivadas.

Como ejemplo, actualmente tengo una jerarquía (no pregunte por la razón de ser de los nombres, pero son significativos en el contexto y se asignan a nombres de elementos XML).Estoy usando Java, pero creo que la mayoría de las lenguas serían similares:

public abstract class Marker {...} 
public class Template extends Marker {...} 
public class Regex extends Marker {...} 

ahora estoy tendiendo hacia:

public abstract class Marker {...} 
public class TemplateMarker extends Marker {...} 
public class RegexMarker extends Marker {...} 

en lugar de

public abstract class AbstractMarker {...} 
public class Template extends AbstractMarker {...} 
public class Regex extends AbstractMarker {...} 

o

public abstract class AbstractMarker {...} 
public class TemplateMarker extends AbstractMarker {...} 
public class RegexMarker extends AbstractMarker {...} 

Yo personalmente puedo recordar que Marker es un concepto funcional abstracto y las subclases son implementaciones concretas.

Answer 9

Yo no lo llamaría clases abstractas Resumen por la siguiente razón:

Cada rectángulo es una forma de . En cualquier lugar donde puedas usar una Forma, puedes usar un Rectángulo. El código que se ocupa de un rectángulo (pero que también se puede tratar con círculos) podría ser:

Shape s = .....; 
s.drawTo(myGraphicsContext); 

El uso de un objeto (por ejemplo, un rectángulo) en cualquier lugar se puede utilizar una generalización de la misma (por ejemplo, una Forma) es un importante parte del concepto orientado a objetos, y conocido como Liskov Substitution Principle. (También es obvio: ¿qué tipo de oración o lógica haría afirmaciones sobre formas, pero luego no sería aplicable a rectángulos?)

Si nombra la generalización como AbstractShape, se infringe este principio. Un rectángulo no es una forma abstracta. ¡Si algo es una "Forma Concreta"! Un rectángulo no es abstracto (en el sentido de "No sé qué tipo de forma es esta. Podría ser un rectángulo, podría ser cualquier otra cosa"). Código usando AbstractShape entonces lee mal:

AbstractShape s = new Rectangle(...); 

blogged con más pensamientos sobre este tema here.