Este es el tercer post de la serie Implementando SOLID, la cual surge de compartir con otros colegas las resoluciones que cada uno implementaría al aplicar los principios SOLID. En esta ocasión vamos a implementar el principio de sustitución de Liskov pero antes de comenzar les comparto los links a otras resoluciones:
Resolución por Fernando: http://blog.kudewe.com/2012/08/implementando-solid-lsp.html
Liskov substitution principle:
El principio de sustitución de Liskov junto al principio abierta cerrado (OCP) son los que nos definen el camino para aplicar correctamente la herencia en el diseño orientado a objetos. Esto se debe a que, juntos, dan robustez al diseño y con robustez me refiero a la “capacidad para adaptarse a los cambios” en forma estable. Mientras que OCP hace que nuestro diseño pueda evolucionar de forma “segura” (principalmente utilizando herencia), LSP nos marca el camino de esa evolución para no abusar de dicha herencia.
Siguiente con los ejercicios utilizados en el evento, refactorizaremos el llamado LSP.MailBuilder de la siguiente forma:
- Ejecutamos los tests, todo verde, empezamos a refactorizar.
- Identificamos al método WithEntity de la clase ContactInformationMailBuilder como el objetivo de nuestra refactorización, según LSP no debería ser necesario conocer las clases derivadas de ContactInformation para funcionar, sino que debería funcionar con la clase base (en este caso ContactInformation) siendo sus derivadas las encargadas de extender el comportamiento.
- Pasamos el método ParseContactInformation a la clase ContactInformation.
- Ejecutamos los tests, todos verde.
- Sobrescribimos el método ParseContactInformation en la clase ContactInformationSubsidiary, agregando el comportamiento del método ParseContactInformationSubsidiary.
- Ejecutamos los tests, todos verde.
- Sobrescribimos el método ParseContactInformation en la clase ContactInformationAuction, agregando el comportamiento del método ParseContactInformationAuction.
- Ejecutamos los tests, todos verde.
En este momento, la familia de la clase ContactInformation aun tiene una pequeña responsabilidad en el parseo y es la de determinar la forma de relacionar el nombre de la propiedad con el valor, para solucionar esto hacemos un refactor mas: “Cambiar los parámetros de AddBodyLine a propertyName y propertyValue”.
Por último y para respetar el principio de responsabilidad única (SRP), podríamos hacer que el parser sea un objeto aparte y no una Action (callback), separando así la responsabilidad de parsear un ContactInformation de la de construir un Mail.
Otros artículos de la serie:
- Principio de responsabilidad única
- Principio abierto / cerrado
