You are on page 1of 4

http://www.adictosaltrabajo.

com/tutoriales/soli
d-3/

Los principios SOLID para diseño de objetos
Publicado: Lunes, 04 Febrero 2013 15:47

Seguramente muchos escuchamos hablar sobre los principios SOLID
para crear diseños orientados a objetos: son una excelente guía general de 5 principios
que, si seguimos, nos facilitarán la creación de sistemas mantenibles y flexibles.
Lo interesante de los principios SOLID es que aplican a cualquier lenguaje orientado a
objetos, ya que son buenas prácticas de diseño probadas en el tiempo. Vamos a
repasarlos!

¿Qué es SOLID?
SOLID es un acrónimo para 5 principios de diseño de objetos, que lo usó por primera vez
Michael Feathers en base a los "primeros cinco principios" de diseño y programación
enunciados por Robert Martin en el año 2000. Estos principios se aplican todos juntos, y
ayudan a que los sistemas sean más mantenibles y fáciles de extender en el tiempo. Se
pueden aplicar los principios SOLID en código existente como guía para realizar un
refactor, y durante la misma codificación junto con prácticas como TDD o Pair
Programming.
SOLID es un acrónimo en inglés de:

S: Principio de Responsabilidad Única (Single Responsability Principle)
"Un objeto debe tener una única responsabilidad"
O: Principio de Abierto / Cerrado (Open / Closed Principle)
"las entidades de software deben ser abiertas a la extensión y cerradas a la
modificación"
L: Principio de Sustitución de Liskov (Liskov Substitution Principle)
"los objetos de un programa deben poder reemplazarse por instancias de sus subtipos
sin alterar la correctitud del programa"

función. El código que sigue este principio no cambia cuando se extiende. donde se suelen necesitar revisiones de código. La implementación puede reutilizarse a través de la herencia. pensemos en un módulo que compila e imprime un reporte. Se define como responsabilidad al motivo de cambio. Su idea era que una vez que una clase estaba completa. módulo. y el polimórfico. y segundo. aunque pueden cambiarse las especificaciones . sólo debía modificarse para corregir errores. El principio de responsabilidad única dice que estos dos aspectos del problema en realidad son dos responsabilidades diferentes. Todos los servicios de la clase deben estar estrictamente alineados a esta responsabilidad. puede cambiar el formato del reporte. por lo que se simplifica el esfuerzo. puede cambiar el contenido del reporte. y dicha responsabilidad debe estar encapsulada por completo por la clase.) debe ser abierta a extensiones y cerrada a modificaciones. O: Principio de Abierto / Cerrado Este principio indica que una entidad de software (clase. Este principio se define con dos enfoques distintos: el de Meyer. por lo que una clase o módulo debería tener una. Bertrand Meyer es quien introdujo este principio en 1988. y la otra en cosmética. Esto se torna especialmente importante en entornos productivos. razón para cambiar. Estos dos cambios son causas muy distintas. que esta entidad permite alterar su comportamiento sin modificar su código fuente. y por lo tanto deberían existir en clases o módulos separados. La definición de Meyer hace uso de la implementación por herencia. pruebas unitarias y otros procedimientos para asegurar su funcionamiento. Este módulo puede cambiarse por dos razones: primero. nuevas características o cambios deberían realizarse en una clase nueva. una es en esencia.  I: Principio de Segregación de Interfaces (Interface Segregation Principle) "es preferible muchas interfaces específicas de cliente que una interfaz de uso general" D: Principio de Inversión de Dependencias (Dependency Inversion Principle) "debemos depender de las abstracciones y no de las concreciones" S: Principio de Responsabilidad Única Este principio de diseño de objetos indica que cada clase debe tener una única resposanbilidad. Esta clase podía reusar el código de la original a través de la herencia. Genera un mal diseño acoplar dos cosas que cambiar por motivos distintos en momentos distintos. Es decir. y solo una. etc. Por ejemplo.

de la interfaz. si S es un subtipo de T. en donde se invierte la relación tradicional de dependencia establecida entre los módulos de alto nivel y los de bajo nivel. y las nuevas implementaciones no necesitan implementar la interfaz existente. . aunque podría no reutilizarse las implementaciones. cambios y redespliegues. Las abstracciones no deben depender de detalles. por lo tanto. Los módulos de nivel superior no deben depender en módulos de niveles inferiores. hacer que sea más facil realizar refactors. entonces los objetos de tipo T pueden ser reemplazados por objetos de tipo S sin alterar ninguna de las propiedades deseables del programa. Ambos deben depender de abstracciones. mínimamente. y las nuevas implementaciones deben. D: Principio de Inversion de Dependencias Este principio de la orientación a objetos se refiere a un tipo particular de desacoplamiento. L: Principio de Sustitución de Liskov Este principio indica que. Durante 1990. Se puede reutilizar la especificación de las interfaces a través de la herencia. A diferencia del uso de Meyer. el principio de Abierto / Cerrado se redefinió para referirse al uso de las interfaces abstractas. La interfaz existente es cerrada a modificaciones. en un programa de computación. Este principio indica que: A. I: Principio de Segregación de Interfaces Este principio indica que ningún cliente debería verse forzado a depender en métodos que no utiliza. esta definición fomenta la herencia de clases base abstractas. implementar esta interfaz. en donde las implementacionse pueden cambiarse y se pueden crear múltiples implementaciones y sustituirlas polimórficamente entre si. El principio separa las interfaces que son muy grandes en interfaces más pequeñas y específicas. de manera que los clientes sólo tengan que conocer los métodos que les interesan. B. Los detalles deben depender de abstracciones. La implementación existente está cerrada a modificaciones. El objetivo del principio de Segregación de Interfaces es mantener un bajo acoplamiento en el sistema y.

Existen otros patrones de diseño (como Plugin. ya que tanto los objetos de nivel superior como los inferiores dependen de abstracciones. Esto se logra separando a los componentes de alto y bajo nivel en paquetes/librerías separadas. . los componentes de alto nivel dependen directamente de los componentes de bajo nivel para realizar sus tareas. en donde las interfaces que definen el comportamiento requerido por un componente de alto nivel existen en el paquete de este componente de alto nivel.Este principio invierte la forma en que las personas piensan sobre el diseño de objetos. El objetivo del Principio de Inversión de Dependencias es desacoplar a los componentes de alto nivel de los componentes de bajo nivel. quienes a su vez permiten construir sistemas más complejos. Un componente de bajo nivel necesitará depender del componente de alto nivel (por la interfaz). En esta composición. y de ahí que se "invierte" la relación tradicional de dependencias. Service Locator y Dependency Injection) que facilitan la creación de estos componentes de bajo nivel y asignación a los componentes de alto nivel. de manera que sea posible la reutilización de los componentes de alto nivel al usar componentes de bajo nivel distintos. En las arquitecturas de aplicación convencionales. se diseña a los componentes de bajo nivel para que sean consumidos por compoenntes de alto nivel. Esta dependencia con los componentes de bajo nivel limitan las oportunidades de reutilización de los componentes de alto nivel.