Los nombres tienen la oportunidad de transmitir significado. ¿Por qué desperdiciarías esa oportunidad con Impl?
En primer lugar, si solo tendrá una implementación, elimine la interfaz. Crea este problema de nombres y no agrega nada. Peor aún, podría causar problemas con firmas de métodos inconsistentes en las API si usted y todos los demás desarrolladores no tienen cuidado de usar solo la interfaz.
Dado eso, podemos suponer que cada interfaz tiene o puede tener dos o más implementaciones.
Si solo tiene uno en este momento y no sabe de qué manera el otro puede ser diferente, Default es un buen comienzo.
Si tiene dos en este momento, nombre cada uno de acuerdo a su propósito.
Ejemplo: Recientemente, tuvimos un contexto de clase concreto (en referencia a una base de datos). Se dio cuenta de que necesitábamos poder representar un contexto que estaba fuera de línea, por lo que se utilizó el nombre Context para una nueva interfaz (para mantener la compatibilidad con las API antiguas), y se creó una nueva implementación, OfflineContext . ¿Pero adivinen el nombre del original? Así es, ContextImpl (yikes).
En este caso, DefaultContext probablemente estaría bien y la gente lo obtendría, pero no es tan descriptivo como podría ser. Después de todo, si no está fuera de línea , ¿qué es? Entonces fuimos con: OnlineContext .
Caso especial: uso del prefijo "I" en las interfaces
Una de las otras respuestas sugirió usar el prefijo I en las interfaces. Preferiblemente, no necesitas hacer esto.
Sin embargo, si necesita una interfaz, para implementaciones personalizadas, pero también tiene una implementación concreta primaria que se usará con frecuencia, y el nombre básico para ella es demasiado simple como para renunciar a una interfaz sola, entonces puede considerar agregar "I" a la interfaz (sin embargo, está completamente bien si todavía no es adecuado para usted y su equipo).
Ejemplo: muchos objetos pueden ser un "EventDispatcher". Por el bien de las API, esto debe ajustarse a una interfaz. Pero también desea proporcionar un despachador de eventos básico para la delegación. DefaultEventDispatcher estaría bien, pero es un poco largo, y si va a ver el nombre a menudo, es posible que prefiera utilizar el nombre base EventDispatcher para la clase concreta e implementar IEventDispatcher para implementaciones personalizadas:
/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
/* default event dispatcher */
}
/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
/* default event dispatcher. */
}