[.NET] Principio de Segregación de Interfaces (I)

Antes de ir al meollo del asunto quiero hacerles recordar que estos Principios de Diseño Orientado a Objetos son solo sugerencias para tener un código ordenado y de fácil mantenimiento, no son ninguna suerte de mandato o de obligatoria práctica, listo continuemos.

Estoy seguro que en más de una ocasión han visto algo así:

No se preocupen, ver uno o dos puede ser normal, pero tener muchas clases similares a la siguiente, puede significar que hay algo que podemos mejorar.

Cuando diseñamos aplicaciones debemos tener cuidado en como es que vamos a trabajar con interfaces ya que si bien nos pueden ayudar a abstraer varios módulos, un uso inadecuado puede llevarnos a forzar la implementación de métodos o funciones que realmente no usaremos. Ahora conozcamos el Principio de Segregación de Interfaces, el cual sostiene lo siguiente:

Los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan, y no aquellos que no necesitan usar.

Entonces, algo muy práctico que podríamos hacer, para esta ocasión, es segregar estas operaciones de la siguiente manera:

Y de esta forma, volviendo a nuestro ejemplo, tendríamos algo así:

Hemos dado un paso y sé que la ausencia de la interfaz IRepository podría traer algunas dudas, probablemente algunos se hayan dado cuenta que hemos tomado como ejemplo una suerte de implementación del Patrón de Repositorio ó Repository Pattern y he hecho esto intencionalmente porque quiero compartirles que existe una estrecha relación entre la inadecuada implementación de un patrón de diseño con el hecho de infringir un principio de diseño, pero ya será en otra ocasión dónde comparta más sobre este patrón.

Ahora lo que quiero hacer es compartir otro ejemplo, uno que responde al Principio de Segregación de Interfaces, pero desde otro punto de partida. Supongamos una clase que hace una serie de operaciones de utilidad.

Si recordamos, esta clase no esta cumpliendo con el Principio de Responsabilidad Única, pero en vez de crear nuevas clases para este ejemplo, crearemos un par de interfaces del siguiente modo:

De tal manera que podríamos tener, por ejemplo, con la implementación de una de ellas (ILogger.cs) una alternativa para cada ocasión que se requiera ya se que tengamos o no acceso a internet o necesitemos un mayor o menor nivel de confidencialidad o respuesta. En cualquier parte de nuestro sistema.

Y eso es todo amigos, queda pendiente el último principio de diseño orientado a objetos y el patrón de repositorio.