c# Object oriented design – ¿Qué tan SOLID es tu código?

Si al leer el nombre del post te has preguntado ¿Qué significa SOLID? y ¿Qué tiene que ver con el diseño orientado a objetos? te recomiendo que sigas leyendo.
Principios SOLID
Principios SOLID


Artículos relacionados:

En la actualidad cuando estudiamos, peor aun cuando ya estamos trabajando, no llegamos a entender correctamente que significa un diseño orientado a objetos, muchas veces se cree que por trabajar con un lenguaje orientado a objetos, como c# o java, y crear clases ya estamos diseñando el código de esa forma. Además, pensamos que la programación estructurada es solo un fantasma del pasado que no se ve en los lenguajes modernos de alto nivel, lo cual es una gran mentira. El código estructurado está más cerca de nosotros de lo que nos imaginamos. Por lo tanto el lenguaje de programación que usemos puede ser orientado a objetos, pero somos nosotros los que finalmente escribimos el código  y por lo general lo hacemos de forma estructurada. Hagamos mea culpa de todos nuestros pecados hechos en el código:

  • Cuantas veces te has topado con clases o métodos que contiene cientos o miles de líneas de código.
  • Cuantas veces dentro de una clase o método encuentras todo tipo de funcionalidad: Log, Manejo errores, Sesión, etc.
  • Cuantas veces has encontrado muchas sentencias if o switch dentro de un método.
  • Cuanto código repetido y mal escrito hay en toda tu aplicación.
  • Cuantas veces ni nosotros mismos entendemos el código que hemos escrito.
  • Cuantas veces hacer un cambio toma más de lo necesario por la forma en como hemos diseñado el código.

Recuerden un buen diseño de software debe ser ligero, flexible y fácil de entender y mantener.

¿Qué es SOLID?

Es un acrónimo introducido por Robert C. Martin a comienzos de la década del 2000. Tengamos presente que SOLID solo son un conjunto de principios que se pueden aplicar en cualquier lenguaje de programación orientado a objetos; por lo tanto no es un framework, no es una librería y no está amarrado a ninguna tecnología. El propósito de SOLID es hacernos más productivos generando código fácil de mantener y extender; y sobre todo nos garantiza que estamos trabajando de una forma orientada a objetos.

Nota: Recordemos que SOLID son un conjunto de principios que deben ser tomados como guías, no reglas. Lo recomendado es usar nuestro cerebro para hacer lo que tenga más sentido ;).

Principios SOLID

SOLID representa cinco principios básicos de la programación orientada a objetos y el diseño:

1. Single Responsability Principle (Principio Responsabilidad Única)

Cada clase debe tener una única responsabilidad. Una clase debe tener una, y solo una, razón de cambio, también aplica a nivel de métodos de una clase.

2. Open Closed Principle (Principio Abierto/Cerrado)

Una clase debe ser abierta para extender, pero cerrada para modificar. Uno debe ser capaz de extender el comportamiento de una clase, sin modificar su contenido.

3. Liskov Substitution Principle (Principio Sustitución Liskov)

Una clase derivada puede ser reemplazada por cualquier otra que use su clase base sin alterar su correcto funcionamiento.

4. Interface Segregation Principle (Principio Segregación de Interfaz)

Define interfaces pequeñas que resuelvan un problema específico (Role Interface) en lugar de tener interfaces grandes que  hagan muchas cosas (Head Interface). Los clientes no deben ser forzados a implementar interfaces que ellos no necesiten.

5. Dependency Inversion Principle (Principio Inversión de Dependencia)

Los módulos de alto nivel no deben depender de los módulos de bajo nivel ambos deben depender de abstracciones (Interfaces, Clases abstractas), no de clases concretas.

¿Cuándo usar SOLID?

SOLID nació como una reacción a un conjunto de design smells. Por design smells hablamos de síntomas, introducidos en el diseño, que indican la violación de algún principio del diseño orientado a objetos. Se recomienda aplicar los principios SOLID si tu código sufre alguno de los siguientes síntomas:

1. Rigidez:

Es la tendencia a que el software sea difícil de cambiar, aun con cambios simples. Ocurre cuando un simple cambio causa que se tengan que volver a compilar los módulos dependientes. Mientras más módulos se tengan que cambiar, más rígido es el diseño. A medida que la rigidez de un módulo aumenta los tiempos asignados para los cambios también aumentan.

2. Fragilidad:

Es la tendencia a que el software se rompa en muchas partes cuando se hace cambio. Ocurre cuando un cambio hecho en un módulo externo genera problemas en lugares que no tienen relación. A medida que la fragilidad de un módulo aumenta la probabilidad que un cambio introduzca nuevos problemas también  aumenta.

3. Inmovilidad:

Significa que el diseño de un sistema es difícil de reutilizar. Ocurre cuando un sistema contiene partes que pueden ser reutilizadas por otros, pero el esfuerzo para separarlas es muy grande. A medida que la inmovilidad de un sistema aumenta la probabilidad de volver a cometer los mismos errores también aumenta.

4. Viscosidad:

El diseño hace que sea difícil hacer lo correcto a nivel de software y ambiente de desarrollo. Seguir la estrategia propuesta versus aplicar soluciones alternativas. Ocurre cuando es más fácil hacer mal las cosas (usar soluciones alternas) que hacerlas bien (seguir la estrategia propuesta).  A medida que la viscosidad de un sistema aumenta ocasiona que existan muchas formas de hacer lo mismo.

5. Complejidad Innecesaria: (El más importante de todos)

Son los elementos que no se utilizan actualmente en el diseño y fueron agregados para soportar necesidades que no existen, ni van a existir. Ocurre cuando se quiere desarrollar una librería de propósito general y se empieza a soñar con cualquier tipo de cosas extrañas que probablemente nunca se van a necesitar. A medida que la complejidad aumenta el código se vuelve más difícil de entender.

6. Repetición innecesaria:

Usar Ctrl+v y Ctrl+c a través de todo el sistema. Ocurre cuando al corregir un bug se tiene que buscar en toda la solución para encontrar cada implementación hecha con el mismo código. A medida que el código repetido aumenta en un módulo  se vuelve más complicado darle mantenimiento.

7. Opacidad:

La tendencia de un módulo a ser difícil de entender. Ocurre cuando el código evoluciona con el tiempo y se vuelve más difícil de entender. A medida que la opacidad aumenta en un sistema  se vuelve más complicado darle mantenimiento y agregar nuevas funcionalidades.

Sugerencias para prevenir los design smells

El blog M.H. Jongerius nos da las siguientes recomendaciones:

  1. Tomar decisiones de arquitectura junto a otros compañeros.
  2. Asegurar que las partes más críticas del sistema cuenten con pruebas unitarias.
  3. Contar con una guía de buenas prácticas de codificación para el equipo.
  4. Para algún cambio o una nueva funcionalidad, se debe invertir tiempo en refactorizar el código.
  5. Hacer programación en pares cuando se implemente un cambio complejo.
  6. Revisar el código de los demás.
  7. Lo perfecto es el enemigo de lo bueno, no tratar de crear diseños perfectos que con llevan a una complejidad innecesaria.

Nota: En los próximos artículos veremos cada uno de los principios SOLID a más detalle.

Conclusión

Al mencionar SOLID hablamos de un conjunto de principios, no de ningún framework o librería. SOLID no está amarrado a ninguna tecnología y puede ser usado en cualquier lenguaje de programación. SOLID son 5 principios: Responsabilidad única, Open/Closed, Sustitución Liskov, Segregación de interfaces e Inyección de dependencias. Sirve aplicar SOLID solo cuando suframos de alguno de estos síntomas en el diseño: Rigidez, Fragilidad, Inmobilidad, Viscosidad, Sobre diseño, Repetición innecesaria u Opacidad.

Si te gusto este post entonces por favor ayúdame a difundirlo y logremos que el conocimiento se expanda, para lograr esto dale me gusta, compártelo en tus redes sociales a tus amigos o suscríbete a mi canal RSS, Gracias :).
Referencias:
Metal Tip:

Este artículo lo escribí escuchando la canción El Guardian de Troya de la banda de WarCry de España, les comparto el enlace. Happy coding and Stay Heavy lml

Anuncios

4 comentarios en “c# Object oriented design – ¿Qué tan SOLID es tu código?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s