patterns over biology oop inheritance coding-style

oop - over - Usar "Base" en un nombre de clase



inheritance oop (12)

"Todas sus bases de clase son de nosotros".

Me alineé con un no definitivo, con una sola excepción. Si estás escribiendo una aplicación para administrar instalaciones militares o estadios de béisbol, apúntate.

¿Es aceptable usar la palabra ''Base'' en un nombre de clase que está en la parte inferior del árbol de herencia?

Siempre me ha resultado un poco difícil, solo me pregunto si alguien está de acuerdo conmigo.

Por ejemplo, si estoy refaccionando ciertos elementos de MyClassA y MyClassB en una clase base común, me sentiría tentado de crear un MyBaseClass del que los dos hereden.

Pero, ¿qué sucede si alguna vez necesito refactorizar MyBaseClass? MyBaseBaseClass? Ahora eso es tonto.

Sé que a Rocky Lhotka no le molesta su marco CSLA, pero siempre me incomodan las ''definiciones'' de programación.

¿Pensamientos?

Déjame aclarar por qué estoy incluso preocupándome por esto.

Tengo dos espacios de nombres: MySpecificNamespace y MyCommonNamespace. MyNamespace usa MyCommonNamespace, como era de esperar.

Ahora, me gusta aprovechar al máximo los espacios de nombres siempre que sea posible para describir el contexto del problema y evitar agregar el contexto al nombre de la clase. Entonces, por ejemplo, considere que tengo una clase en MyNamespace que desciende de una en MyCommonNamespace.

Opción A

Podría llamar esto

MySpecificClass: MyClass { }

Pero luego agrego ''Specific'' (el contexto) al nombre, que es redundante porque ya está en MySpecificNamespace.

Opción B

MyClass: MyCommonNamespace.MyClass { }

Puedes ver cómo podemos confundirnos aquí, ¿verdad?

Opción C

El que creo que es sospechoso:

MyClass: MyBaseClass { }


¡Creo que debería evitarse, siempre que sea posible, a favor de un identificador que realmente describa lo que es!

Esta pregunta es difícil de responder porque es abstracta. Podría, por ejemplo, considerar llamar a la base de MyClassA y MyClassB, "MyClass".


Creo que vale la pena wiki-fying esta pregunta.

FWIW, estoy de acuerdo. Normalmente trato de encontrar un término más "genérico" para mis clases base. Entonces, si tengo una clase de "Cliente" y necesito introducir una nueva clase base para ella, elegiría "Contacto" o algo en lugar de "CustomerBase".


En Java tiendo a proporcionar una implementación básica de una interfaz Foo en una clase abstracta FooBase. Creo que está perfectamente bien y hace que la conexión a la interfaz sea muy clara y regular.

Sin la interfaz, llamaría a la clase base abstracta Foo.


Estoy de acuerdo con el "no" por el motivo de la refactorización que has citado.

Una clase debe nombrarse después de lo que representa lógicamente, y nada más que la clase Object realmente es realmente Base. Metafísica ftw :)

re: Opción B, no hay nada confuso sobre

namespace MySpecificNamespace { MyClass: MyCommonNamespace.MyClass { } }


Estoy de acuerdo, AbstractFoo es una solución decente. Intento elegir nombres que no necesiten adjetivos adicionales. Me rehusaría a usar Base.


Las clases que tienen el mismo nombre que sus clases principales me molestan infinitamente. En Java java.sql.Date extiende java.util.Date. Esto es muy molesto porque debe especificar la clase exacta que desea importar o especificar el nombre de clase por completo (incluido el paquete / espacio de nombres).

Personalmente prefiero nombrar las cosas como son; si una clase base o abstracta existe solo para proporcionar una implementación parcial de algo, y no representa la interfaz para esa cosa, a menudo es aceptable poner la palabra abstracta o base en su nombre. Sin embargo, si esa clase también representa la interfaz, entonces debería nombrarla después de lo que hace.

Por ejemplo, en Java, tenemos la interfaz de conexión (para conexiones DB). Simplemente se llama Connection, no IConnection. Lo usas así:

Connection con = getConnectionFromSomewhere();

Si está creando un controlador JDBC y necesita implementar una conexión, podría tener ConnectionBase o AbstractConnection, que es la capa inferior de los detalles de implementación de su Conexión en particular. Es posible que usted tenga

abstract class AbstractConnection implements Connection class OracleConnection extends AbstractConnection

o algo así. Los clientes de su código, sin embargo, nunca ven AbstractConnection ni ven OracleConnection, solo ven Connection.

Por lo tanto, en general, las clases que deben ser generalmente útiles deben nombrarse después de lo que representan / hacen, mientras que las clases que son auxiliares para el mantenimiento / organización del código pueden nombrarse después de lo que son.

* ps Odio nombrar Interfaces con I. ¿Las personas nombran todas sus clases con C? ¡Es 2009! su IDE puede decirle qué tipo de objeto es, en el caso extraño, incluso si es una interfaz o una clase.


Normalmente uso IFoo para la interfaz y AbstractFoo para la implementación esquelética, que es una combinación de convenciones de .NET y Java.


También estoy al lado del campamento no ... pongo una Base ahí hoy y en 6 meses alguien golpeará una clase MyDerivedClass en tu base de código mientras no estés mirando.


Tiendo a agregar un sufijo Base al nombre de la clase base solo si existe desde la perspectiva técnica (para compartir algún código), y realmente no constituye ninguna clase utilizable en sí misma (por lo que todas estas clases son abstractas). Sin embargo, estos son casos bastante raros, y deberían evitarse como las clases de Helper.


Yo también sugeriría No, pero no en piedra ...

Siguiendo el mantra OO, su sistema de nombres debería representar mejor los objetos subyacentes que se supone que el código está encapsulando. Realmente no debería haber un ''metalenguaje'', relacionado con la composición sintáctica real del lenguaje de programación elegido aquí.

Dicho eso, si su objeto es realmente abstracto y realmente no lo ve cambiar pronto, hay un argumento que agrega que ''Base'' ayuda con la legibilidad general.

Al igual que con la mayoría de las cosas, no existe una respuesta correcta correcta o incorrecta: depende del diseño general de la base de código, qué se supone que representa este código específico y el estilo interno que tiene. Solo trata de ser consistente.

¿La base se usa en otro lado?


Prefijo "abstracto" tal vez?