A las interfaces les gustan las multitudes

Sigo con mi cruzada anti interfaces en proyectos normales Java con un consejo.

Si has hecho una interface y solo tienes una clase que implemente esa interface, quizá debieras reconsiderar si realmente necesitas una interface.

Dejo algunas reflexiones:

El recurso más utilizado para justificar estas prácticas tienen cierta relación con la adivinación. Pongo una interface y así en el futuro puedo cambiar la implementación.

Pero pregúntate. ¿Que posibilidad hay de que en el futuro se cambie esa implementación? ¿Cuanto te va a suponer de coste hoy esa flexibilidad futura? ¿Es previsible que tu organización cambie, por ejemplo de Oracle a MySQL?

Probablemente te des cuenta de que estás pagando un sobrecoste a día de hoy sin tener ninguna seguridad de que en el futuro lo vayas a recuperar.

Si aun así ves que es probable que pueda cambiar, hazte otra pregunta. ¿Necesito tener las dos implementaciones a la vez?

Lo normal es que no. Así que incluso con el empleo de la interface vas a tener que abrir el código para codificar una nueva implementación. ¿Que diferencia hay con simplemente coger la implementación vieja y cambiarla? Tienes una gestión de la configuración para no perder la versión vieja.

Si aun así en el futuro necesitases la interface y varias implementaciones, los entornos de desarrollo actuales soportan la refactorización y una de ellas suele ser el sacar interfaces de clases.

Así que ten en cuenta, a las interfaces les gustan las multitudes.