Miedo a las interfaces

Mi primer post (no intro) es de programación :S
Igualmente, como todo, tiene un contenido social, y psicológico, pero se va a hacer dificil de entender entre tanta maraña de cosas tecnológicas y conceptos de programación.

La pregunta introductoria al tema es: por qué la gente le tiene miedo al diseño que separa interfaz de implementación ?

Algunos se escudan en la idea de que es sobrediseño hacer esta separación, cuando actualmente solo se desarrola una única implementación.
Cuánto overhead trae este sobrediseño me pregunto ?
Otra pregunta interesante, sería, cuánta penalidad me trae tener que hacerlo después ? Y acá entran muchos factores. Por ejemplo, si trabajo con varios artefactos maven, implicaría reversionar (generar una nueva versión) del artefacto core, y si la dependencia es transitiva a partir de varios otros artefactos, tendré que refactorizar y generar nuevas versiones para cada uno.
Además, de la incompatibilidad de versiones sobre otros clientes que ya codifiqué y liberé.


Otros reniegan del hecho de que al modelarlo con interfaces, se pierde la reutilización de código.

La pregunta acá sería, cuánto código estoy realmente reutilizando ?

Y el otro punto de fondo es: qué tan efectiva es la idea de definir tipos y relaciones entre ellos a través de herencia ?
Está claro, desde el nacimiento de la herencia, que es un mecanismo poco eficaz, para cualquiera de sus dos funciones:

• reutilizar código
• definir tipos (función semántica)
  

Digo desde su creación porque según leí alguna vez en un post, cuando se introdujo esta idea a la implementación de smalltalk, no recuerdo si Alan Kay o Dan Ingalls, decían algo como "no nos convence, pero es lo mejor que pudimos hacer hasta ahora". Dando pié a cuestionamientos sobre este mecanismo.

En un lenguaje sin herencia múltiple, y con checkeos en tiempo de compilación, como java, la interface está directamente asociada con el concepto de polimorfismo, en su estado más puro. Claro, java tampoco tiene duck-typing.

En un lenguaje sin checkeo en tiempo de compilación, esta problemática sería trivial, porque simplemente puedo codificar una nueva impl que entienda los mismos mensajes y ya.
En java, en cambio, yo tengo que establecer el contrato de esos métodos, de antemano.

Entonces, me parece bien recomendar a un desarrollador no-experto, concentrarse en resolver los problemas de a uno, y no meterse a tratar de resolver todo el sistema de golpe. O a meterse en meta-niveles de programación, o meta-tareas.

Ahora, qué tan válido es seguir aplicando ese principio para un programador experimentado ? No está siendo ineficiente, solo por fanatismo ?

De todas estas estructuras mentales (porque, al final, parece que siempre buscamos lo mismo que criticamos, es decir, LA respuesta. LA forma de hacer las cosas que sea invariante, y que siempre aplique a todas las situaciones infaliblemente. El famoso silver bullet, pero conceptual, en este caso.), digo, la más simpática para mí es la de tomarse un minuto para analizar si el concepto que estamos definiendo, es decir el "tipo" merece ser considerado un concepto principal, extensible, o cuya implementación puede tener sentido variar.

Bueno ya. Me perdí un poco del objetivo del post.

Supongo ahora, en retrospectiva, que era cuestionar el por qué las personas le tienen idea a la división de interfaz vs implementación, que es una de esas prácticas que mucha gente hace de memoria. Pero en cambio, no les hacen ruido otras prácticas nefastas como las arquitecturas de DTO, o los dummy beans.

?