¿Debo agregar un prefijo "Resumen" a mis clases abstractas? [cerrado]

Supongamos que tengo una clase abstracta llamada Task.

¿Existe algún estándar o convención que sugiera que debería nombrarlo AbstractTask?

Según el Java efectivo de Bloch (elemento 18), el prefijo abstracto es una convención utilizada en un caso especial.

Puede combinar las virtudes de las interfaces y las clases abstractas al proporcionar una clase de implementación esquelética abstracta que vaya con cada interfaz no trivial que exporte. ... Por convención, las implementaciones esqueléticas se denominan AbstractInterface, donde Interface es el nombre de la interfaz que implementan.

Pero Bloch también señala que el nombre SkeletalInterface habría tenido sentido, pero concluye que

La convención abstracta está ahora firmemente establecida.

Como han señalado otras respuestas, en general no hay razón para aplicar esta convención de nomenclatura a todas las clases abstractas.

No hay convención. Se trata de lo que le ayudará, como desarrollador, a codificar más rápido y mejor, y a ayudar a otros a comprender su código.

Pregunte a las personas que verán y mantendrán el código. ¿Qué preferirían ver? ¿Qué lo hará más fácil para ellos? Luego nómbralo según lo que les gustaría.

En otra nota, las convenciones de código para el lenguaje de programación Java: 9. Las convenciones de nomenclatura no sugieren ningún requisito:

Los nombres de clase deben ser sustantivos, en mayúsculas y minúsculas con la primera letra de cada palabra interna en mayúscula. Intenta mantener los nombres de tus clases simples y descriptivos. Use palabras completas: evite las siglas y abreviaturas (a menos que la abreviatura sea mucho más utilizada que la forma larga, como URL o HTML).

No. Intellisense me dirá trivialmente si es abstracto, así que solo estás violando DRY aquí.

Esto es algo de preferencia (pero es una mala práctica límite), pero a la mayoría de la gente no le gusta ver parte de los calificadores en el nombre de la clase.

De todos modos, la mayoría de los IDE harán que la información esté fácilmente disponible para usted, por lo que no es necesario ponerle el nombre, y será más limpio omitirla. Es una reminiscencia de la notación húngara para nombres variables, y eso ciertamente se considera una mala forma hoy en día. Recomiendo simplemente llamarlo Task.

En .NET, a menudo se ve el uso de "Base" como sufijo para denotar una clase base abstracta. Me referiría a las otras respuestas sobre si esta es una práctica común en Java.

En mi opinión, el nombre de una entidad no debe transmitir información sobre su estructura tipográfica, sino sobre su semántica. Por lo tanto, no tiene sentido definir su clase como "AbstractSomething" si la abstracción no es parte de su objetivo de tiempo de ejecución. Es una clase abstracta base visible para el programador y no necesita reflejarse en el nombre.

Sin embargo, si es perfecto para llamar a una implementación de una fábrica abstracta un AbstractFactory, porque eso se relaciona con la intención de la clase.

En general, favorezca la convención de nomenclatura que ayuda a transmitir la mayor cantidad de información sobre el objetivo de su clase.

Del mismo modo, manténgase alejado de SomethingImpl. No nos importa que sea una implementación y no una clase base. Si su jerarquía de clases está diseñada correctamente para la herencia, entonces alguien podría heredar de ella. Seguramente no tendría valor agregar más sufijos "Impl" u otros artefactos. Tampoco tiene valor agregar un sufijo "Interfaz" o un prefijo "I".

Considerar:

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

Opuesto a:

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

Prefiero el último con diferencia.

Esto, en cierto sentido, es similar al uso indebido descarado de la notación húngara que le dio su mala reputación , ya que la gente comenzó a interpretarlo erróneamente como algo que obligaba a los desarrolladores a prefijar sus variables con un indicador del tipo de variable. Si bien esto a veces puede tener sus usos (principalmente si eres flojo para buscar la definición del tipo), en su mayoría es inútil. La idea original de Simonyi con la notación húngara era usarla como un mnemotécnico para recordarle al desarrollador las capacidades de la entidad, no de su tipo.

Una buena regla general es no incluir propiedades en un nombre que sean obvias por la sintaxis. Como en Java, debe marcar una clase abstracta con la abstractpalabra clave correctamente nombrada , no la incluiría en el nombre. En C ++, por ejemplo, el caso no es tan claro, pero al menos el compilador le dirá cuándo usó incorrectamente una clase abstracta. En algo como Python nuevamente, nombrar explícitamente una clase abstracta como tal no es una mala idea.

La excepción habitual a la regla es cuando el nombre es ambiguo. Si, por alguna razón, hay una subclase concreta Task(en otros ejemplos, esto puede ser más sensible, pero lo que sea), entonces, seguro, úselo AbstractTask.

protected abstract SomeClass { }

Esto me dice que esta es una clase abstracta. Agregar un prefijo es una tautología y un antipatrón y no es apropiado en la mayoría de los casos, vea el enlace donde se habla de package localser una excepción, por ejemplo.

En la mayoría de los casos, las Abstractclases no deberían ser parte de una API pública, si es así, realmente debería haber una buena razón y una buena razón debería proporcionar un nombre obviamente bueno que no sea AbstractSomeClass.

En la mayoría de los casos, si no puede encontrar un nombre más descriptivo, probablemente necesite hacer un nuevo diseño.

Mis cinco centavos, probablemente tendrá implementaciones de esa clase abstracta y se llamarán 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask', etc. Así que no habrá un choque de nombres entre su 'Task' abstracta y ellas.

Además, la palabra "abstracta" se refiere a la sintaxis del lenguaje, no a las entidades de dominio comercial, por lo que preferiría no usarla como parte del nombre.

Por otro lado, en una respuesta aquí vi un extracto de J.Bloch Effective Java que dice que usar 'resumen' como parte de un nombre es una práctica bien establecida. Puede ser asi. Pero de todos modos en las convenciones oficiales de código java no hay nada de eso.

Si trabaja en un equipo, entonces todo el equipo debe decidir si debe prefijar las clases abstractas con "Resumen".

Si trabaja por su cuenta, entonces depende completamente de usted, no yo ni nadie más en este sitio.

No soy un desarrollador de Java (INAJD?) Y no conozco la nomenclatura estándar para tales cosas, pero creo que Tasksuena lo suficientemente abstracto como para que pueda estar solo tal como está.

¿Qué pasa si quieres escribir una AbstractSyntaxTreeclase abstracta ? ¿O tal vez solo un resumen SyntaxTree?

No es convencional y puede confundir fácilmente a las personas.

He hecho esto. Agregué 'Resumen' como prefijo a mi clase abstracta llamada AbstractOperation. La razón por la que hice esto fue porque había otro paquete que tenía una clase no abstracta llamada Operation, y ayudó a mi equipo y a los programadores que se hicieron cargo más adelante para evitar cualquier confusión entre los dos.