Interfaces Java / Convención de nomenclatura de implementación [duplicar]

He visto respuestas aquí que sugieren que si solo tiene una implementación, entonces no necesita una interfaz. Esto va en contra del principio de Inyección/Inversión de Control de Dependencia (no nos llame, le llamaremos!).

Así que sí, hay situaciones en las que desea simplificar su código y hacerlo fácilmente comprobable confiando en implementaciones de interfaz inyectadas (que también pueden ser proxy - su código no lo sabe!). Incluso si solo tiene dos implementaciones: una un simulacro para pruebas, y uno que se inyecta en el código de producción real-esto no hace que tener una interfaz sea superfluo. Una interfaz bien documentada establece un contrato,que también se puede mantener mediante una implementación de prueba estricta.

De hecho, puede establecer pruebas que tengan simks implementen el contrato de interfaz más estricto (lanzando excepciones para argumentos que no deberían ser nulos, etc.) y detectar errores en las pruebas, utilizando una implementación más eficiente en código de producción (no comprobar argumentos que no deberían ser null por ser null ya que el simulacro arrojó excepciones en sus pruebas y usted sabe que los argumentos no son null debido a la fijación del código después de estas pruebas, por ejemplo).

La inyección de dependencia / IOC puede ser difícil de entender para un recién llegado, pero una vez que entienda su potencial, querrá usarlo en todo el lugar y se encontrará haciendo interfaces todo el tiempo, incluso si solo habrá una (producción real) aplicación.

Para esta implementación (puede inferir, y estaría en lo correcto, que creo que las burlas para las pruebas deberían llamarse Mock(InterfaceName)), prefiero el nombre Default(InterfaceName). Si se presenta una implementación más específica, se puede nombrar apropiadamente. Esto también evita el sufijo Impl que particularmente me disgusta (si no es una clase abstracta, POR SUPUESTO que es un "impl"!).

También prefiero "Base (InterfaceName)" en lugar de "Abstract (InterfaceName) "porque hay algunas situaciones en las que desea que su clase base se convierta en instanciable más tarde, pero ahora está atascado con el nombre" Abstract(InterfaceName)", y esto lo obliga a cambiar el nombre de la clase, posiblemente causando una pequeña confusión, pero si siempre fue Base(InterfaceName), eliminar el modificador abstracto no cambia lo que era la clase.

El nombre de la interfaz debe describir el concepto abstracto que representa la interfaz. Cualquier clase de implementación debe tener algún tipo de rasgos específicos que se puedan usar para darle un nombre más específico.

Si solo hay una clase de implementación y no se puede pensar en nada que la haga específica (implícita por querer nombrarla -Impl), entonces parece que no hay justificación para tener una interfaz en absoluto.

Tiendo a seguir las pseudo-convenciones establecidas por Java Core / Sun, por ejemplo, en las clases de Colecciones:

• List - interfaz para el objeto" conceptual "
• ArrayList - implementación concreta de interface
• LinkedList - implementación concreta de interface
• AbstractList - implementación abstracta "parcial" para ayudar a las implementaciones personalizadas

Solía hacer lo mismo modelando mis clases de eventos según el paradigma AWT Event/Listener/Adapter.

La convención estándar de C#, que también funciona bastante bien en Java, es prefijar todas las interfaces con un I - por lo que su interfaz de controlador de archivos será IFileHandler y su interfaz de camión será ITruck. Es consistente y hace que sea fácil distinguir las interfaces de las clases.

Me gustan los nombres de interfaz que indican qué contrato describe una interfaz, como "Comparable" o "Serializable". Los sustantivos como "Camión" realmente no describen el camión what ¿cuáles son las Habilidades de un camión?

Con respecto a las convenciones: He trabajado en proyectos donde cada interfaz comienza con una "I"; aunque esto es algo ajeno a las convenciones de Java, hace que encontrar interfaces sea muy fácil. Aparte de eso, el sufijo "Impl" es un nombre predeterminado razonable.

A algunas personas no les gusta esto, y es más una convención. NET que Java, pero puede nombrar sus interfaces con un prefijo I mayúscula, por ejemplo:

IProductRepository - interface
ProductRepository, SqlProductRepository, etc. - implementations

Las personas que se oponen a esta convención de nomenclatura podrían argumentar que no debería importarle si está trabajando con una interfaz o un objeto en su código, pero me resulta más fácil de leer y entender sobre la marcha.

No nombraría la clase de implementación con un sufijo "Class". Eso puede llevar a confusión, porque usted puede en realidad trabaja con objetos" class " (es decir, Type) en su código, pero en su caso, no está trabajando con el objeto class, solo está trabajando con un objeto simple.

TruckClass suena como si fuera una clase de Truck, creo que la solución recomendada es agregar Impl sufijo. En mi opinión, la mejor solución es contener dentro del nombre de la implementación alguna información, lo que está pasando en esa implementación en particular (como tenemos con List interfaz e implementaciones: ArrayList o LinkedList), pero a veces solo tiene una implementación y tiene que tener interfaz debido al uso remoto (por ejemplo), entonces (como se mencionó al principio) Impl es la solución.

Utilizo ambas convenciones:

Si la interfaz es una instancia específica de un patrón bien conocido (por ejemplo, Service, DAO), entonces puede que no necesite una "I" (por ejemplo, UserService, AuditService, UserDao) todo funciona bien sin la "I", porque el post-fix determina el patrón meta.

Pero, si tienes algo único o doble (normalmente para un patrón de devolución de llamada), entonces ayuda a distinguirlo de una clase (por ejemplo, IAsynchCallbackHandler, IUpdateListener, IComputeDrone). Estos son especiales interfaces de propósito diseñadas para uso interno, ocasionalmente la IInterface llama la atención sobre el hecho de que un operando es en realidad una interfaz, por lo que a primera vista es inmediatamente claro.

En otros casos se puede usar la I para evitar colisionar con otras clases concretas comúnmente conocidas (ISubject, IPrincipal vs Subject o Principal).