Reificando el comportamiento - Utilizar una interfaz o una clase abstracta

[LautaroMelchiori]

Hola! Leyendo el apunte sobre cosificacion del comportamiento me resultó super claro el ejemplo expuesto pero me entro una duda con respecto a esta parte en particular:

No termino de entender por qué seria una decisión cuestionable hacer de la interfaz solicitud una clase abstracta con el estado compartido por las implementaciones concretas actuales: no veo una perdida de extensibilidad porque una eventual nueva implementacion concreta podria extender de la superclase y definir los parametros extra que requiera y el polimorfismo se mantendria intacto siempre y cuando implementes los metodo que definis como interfaz, ¿cual es el criterio para elegir entre una interfaz y una clase abstracta en este tipo de situaciones?

[roli93]

Hola @LautaroMelchiori !

Es cuestionable porque no hay ninguna razón para pensar que todas las operaciones diferibles sobre la cuenta vayan a tener tarjeta y monto como parámetros. Podes tener una operación "transferenciaProgramada" que tenga un monto y a otra cuenta. Y entonces qué haces? Definis 3 atributos en la clase padre ("tarjeta", "monto" y ahora "cuenta"?) Vas a tener atributos que no todas las subclases usan. Y fundamentalmente siempre recuerden la máxima de oro: las clases nacen para reutilizar comportamiento. Y las clases abstractas nacen para reutilizar comportamiento entre las clases hijas. Gastarte el mecanismo de herencia (que es un arma de un solo tiro) solo para reutilizar un par de definiciones de atributos es, per se, cuestionable, más allá de este ejemplo concreto.

[LautaroMelchiori]

Clarisimo... gracias!

[ParedesMicaela]

Hola! Tal vez al ver el diagrama se vuelve más evidente por qué este no es el mejor enfoque. Con la clase abstracta obligas a que todas las futuras solicitudes tengan como atributo la tarjeta y el monto, aunque no los necesite.

Esto es un ejemplo de code smell "divergent change", mencionado en la guía de refactoring (https://docs.google.com/document/d/1cAje0qwy3Cus_ob0r-tatbcT01sDFeLt3MmSVmLeSxk/edit?usp=sharing). Este code smell pasa cuando en 1 clase tenemos atributos o métodos para solucionar distintas responsabilidades, que no están relacionadas entre sí. O sea, hacemos que nuestra clase sea poco cohesiva. Lo que sí podríamos hacer, es una clase abstracta para las solicitudes que requieran como atributos una tarjeta y un monto. Esta clase implementaría la interfaz solicitud, de modo que las futuras solicitudes de transacciones, puedan heredar de esta.

[LautaroMelchiori]

Totalmente... con el grafico se ve super claro. Esta bueno pensar en que incluso podes tener una clase abstracta para algunas solicitudes con elementos en comun pero seguir dejando la interfaz de Solicitud generica para una operacion reificada sobre la cuenta. Gracias!!