/ patrones de diseño

Principios de diseño S.O.L.I.D

Historia

SOLID es un acrónimo (compuesto de más acrónimos :P) generado por Robert C. Martín a comienzo de la década de 2000 que representa 5 principios básicos de la Programación Orientada a Objetos y el diseño. SOLID son guías aplicables al desarrollo de software para eliminar código “sucio” por medio de la refactorización.

SOLID es utilizado con mayor frecuencia en el desarrollo guiado por pruebas (TDD) y es parte fundamental de la estrategia de  desarrollo ágil de software y programación adaptativa aunque no se limita a solo estos enfoques.

SOLID se deriva de los siguientes principios:

Single Responsability Principle.

Principio de Responsabilidad Única.

Una clase debe tener una única responsabilidad. Esto quiere decir que una clase debe tener una única razón por la que está justificado realizar cambios sobre su código fuente. Una consecuencia de este principio es que, de forma general, las clases deberían tener pocas dependencias con otras clases/tipos.

Open/Close Principle.

Principio Abierto/Cerrado.

Una clase debe estar abierta para la extensión y cerrada para la modificación. Es decir, el comportamiento de una clase debe poder ser extendido sin necesidad de realizar modificaciones sobre el código de la misma.

Liskov Substitution Principle.

Principio de Sustitución de Liskov.

Los subtipos deben poder ser sustituibles por sus tipos base (interfaz o clase base). Este hecho se deriva de que el comportamiento de un programa que trabaja con abstracciones (interfaces o clases base) no debe cambiar porque se sustituya una implementación concreta por otra. Los programas deben hacer referencia a las abstracciones, y no a las implementaciones. Este principio está muy relacionado con la Inyección de Dependencias y la sustitución de unas clases por otras siempre que cumplan el mismo interfaz

Interface Segregation Principle.

Principio de Segregación de Interfaces.

Las clases que implementen una interfaz de clases no deben estar obligados a implementar métodos que no se usan. Es decir, los interfaces de clases deben ser específicos dependiendo de quién los consume y por lo tanto, tienen que estar divididos/segregados en diferentes interfaces no debiendo crear nunca grandes interfaces. Las clases deben exponer interfaces separados para diferentes clientes/consumidores que difieren en los requerimientos de interfaces.

Dependency Inversion Principle.

Principio de Inversión de Dependencias.

Las abstracciones no deben depender de los detalles . Los detalles deben depender de las abstracciones. Las dependencias directas entre clases deben ser reemplazadas por abstracciones (interfaces) para permitir diseños top-down sin requerir primero el diseño de los niveles inferiores.

En resumen

Si bien estos principios son sencillos de aprender es necesario tenerlos en cuenta en el desarrollo de nuestras aplicaciones ya que simplifican el trabajo y mejoran la estructura de nuestros sistemas haciendo más fácil el trabajo en equipo.

Sin más por el momento me despido de ustedes, ¡Saludos!

Edición 7 agosto 2015

Después de publicar este post en la comunidad Programadores C#(misma a la que invito a que se unan ;) ) he recibido el siguiente comentario de Eduard Tomàs:

Si bien estos principios son sencillos de aprender...
Esa frase es muy peligrosa... los principios SOLID son como el ajedrez... puede ser que "aprenderlos" sea fácil, pero aplicarlos bien es mucho más complicado de lo que parece.

Y me pareció que es importante mencionar que si bien no creo que sea peligroso lo que escribí en esa línea, sí he manifestado ligereza ya que coincido con Eduard en que lograr que nuestros sistemas utilicen los principios S.O.L.I.D requiere de experiencia y mucha práctica para lograr aplicarlos de forma correcta.

Así que una vez agregado el comentario y aclarado el punto puedo dormir en paz jajaja. Saludos.

Saturnino Pimentel

Saturnino Pimentel

Microsoft MVP, consultor, blogger y conferencista. Saturnino es el cofundador de la comunidad de programadores c# y el meetup de c# de la ciudad de México además de participar con otras comunidades.

Read More

Suscríbete a la lista de correos :)

* indicates required