sábado, 4 de agosto de 2012

Implementando SOLID – LSP

Siguiendo con los principios SOLID, y el empuje de Nelo p/compartir como resolver cada uno de los ejercicios, vamos a continuar con el principio de liskov.

Esta es la solución de Nelo: http://nelopauselli.blogspot.com.ar/2012/08/implementando-solid-lsp.html

El código del ejercicio es este:

El problema es que el método WithEntity hace un tratamiento especial para cada una de las subclases. El principio de Liskov nos dice que si dependemos de una clase base, debemos poder usar objetos de clases derivadas sin saberlo. Y este no es el caso. Los problemas que presenta no seguir este principio son:

  • Quien usa el método WIthEnity puede pensar, con todo derecho, que pasándole cualquier objeto derivado de ContactInformation va a funcionar.
  • Quien agrega otro subtipo de ContactInformation, puede olvidarse que existe este método WithEntity con tratamiento especial y usarlo.
  • El ejemplo está reducido y simplificado p/poder ser entendido fácilmente. En realidad se trata de un caso real, con muchos subtipos y una jerarquía algo más compleja. Modificar esta MailBuilder era realmente un problema, ya que implicaba volver a probar todos los casos.
Este código tiene una ventaja que favorece el reuso vs la duplicación, pero una desventaja, que es poco flexible. A veces la duplicación no es mala, ya que nos da flexibilidad. La solución propuesta es tener un MailBuilder por cada clase. Hay duplicación, pero también flexibilidad. Podemos cambiar lo que querramos, sin afectar lo existente.

Seguramente hay otras formas de eliminar la duplicación. Podemos por ejemplo crear un MailBuilderString con la responsabilidad de armar un mail y usar este objeto dentro de cada uno de los MailBuilders para cada ContactInformation.

saludos!