Entiendo los principios de codificación de interfaces: desacoplar la implementación de la interfaz y permitir que las implementaciones de la interfaz se intercambien dentro y fuera.
¿Debo codificar interfaces para cada clase que escribo o es exagerado? No quiero duplicar el número de archivos fuente en un proyecto a menos que realmente valga la pena.
¿Qué factores puedo usar para decidir si codificar por interfaz o no?
Solución
En general, estoy de acuerdo con las otras respuestas: use una interfaz cuando conozca o anticipe un cambio y / o una implementación diferente, o busque la estabilidad.
Pero no siempre es fácil saber de antemano lo que puede cambiar en el futuro, especialmente si no tienes tanta experiencia. Creo que la solución para ese problema es la refactorización: mantenerlo simple (= sin interfaz) siempre que no sea necesario. Cuando surja la necesidad, simplemente haga una refactorización de «Interfaz de introducción / extracción» (compatible con casi todos los IDE decentes).
Cuando lo haga, extraiga solo aquellos métodos que realmente necesitan las personas que llaman. No tenga miedo de extraer más de una interfaz separada (si no todos los métodos extraídos son realmente coherentes).
Un controlador de la refactorización podría ser la prueba: si no puede probar fácilmente algo con clases, solo considere introducir una o algunas interfaces. Esto también le permitirá usar burlas que pueden simplificar enormemente las pruebas en muchos casos.
Editar: basándome en el comentario de Tarski, me he dado cuenta de un escenario / ajuste más importante a las declaraciones anteriores:
si proporciona una API externa (para otros [sub]proyectos, o realmente la libera «a la naturaleza»), entonces el uso de interfaces en la API (excepto para clases de valor simples) es casi siempre una buena idea.
Le permitirá cambiar el impl si lo desea sin molestar el código del cliente. Tendrá un problema solo si también tiene que cambiar la interfaz. No romper la compatibilidad será muy complicado (si no imposible).
Otras respuestas
No, cada clase no debe tener una interfaz. Es exagerado al cuadrado.
Usa una interfaz cuando necesita abstraer lo que se hace de cómo se hace, y está seguro de que la implementación puede cambiar.
Eche un vistazo a la API de colecciones java.util para obtener un buen ejemplo. La interfaz List es una buena abstracción para la idea general de una List, pero puede ver que hay muchas formas de implementarla: ArrayList, LinkedList, etc.
ACTUALIZACIÓN: Entonces, ¿qué pasa con ese caso en el que diseña una clase concreta, decide después de tener clientes que se necesita una interfaz y luego rompe sus clientes agregando una interfaz? Sí, eso es lo que sucede. ¿Cómo puedes saber lo que no sabes? Ningún software o metodología puede arreglar eso.
La buena noticia para usted es que extraer una interfaz de una clase concreta es una refactorización fácil de hacer tanto para usted como para sus clientes. Los IDE manejan ese tipo de cosas de forma rutinaria. Usted y sus clientes deben aprovecharlos.
Yo diría que las capas, como los servicios y la persistencia, siempre deben tener interfaces. Cualquier cosa que pueda ser proxy debe tener una interfaz. Si estás haciendo Spring AOP, cualquier cosa que quieras decorar con un aspecto debe tener una interfaz.
Los objetos de modelo o valor, como Persona o Dirección o Teléfono, no deben tener una interfaz. Un objeto de valor inmutable no debe tener una interfaz.
El resto caen en zonas grises. Usa tu mejor juicio.