Principios SOLID

Principios de diseño
orientado a objetos
Joan Sebastián Ramírez Pérez
2015

Agenda
 ¿Qué diseño queremos?
 SOLID
 DRY
 KISS
 Bibliografía

¿Qué diseño queremos?
 Cohesivo
 Robusto
 Reusable
 Flexible
 Mantenible
 Testeable

¿Cómo nos percatamos de que tenemos
un mal diseño?
Malos olores en el código:
 Rigidez (cambios en cascada).
 Fragilidad (elementos no relacionados se rompen al hacer un cambio).
 Inmovilidad (poco reuso- mucho copy paste).
 Viscosidad.
 Complejidad innecesaria.
 Repetición innecesaria.
 Opacidad.

Motivación
 “El elemento más volátil en los proyectos software son los requisitos. Vivimos en un
mundo de requisitos cambiantes, y nuestro trabajo es estar seguros de que
nuestros software puede sobrevivir a esos cambios, así que no culpes a los
requisitos cambiantes por los fallos en el software.” Robert C. Martin

Agenda
 ¿Qué diseño queremos?
 SOLID
 STUPID
 Bibliografía

¿Qué es SOLID?
 Acrónimo mnemónico introducido por Robert C. Martin a comienzos de la década
del 2000.
 Son cinco principios básicos de la programación orientada a objetos y el diseño.
 Ayudan a desarrollar un software de calidad, legible, entendible y fácilmente
testeable.

¿Qué es SOLID?
 Single Responsibility Principle (SRP)
 Open Closed Principle (OCP)
 Liskov Substitution Principle (LSP)
 Interface Segregation Principle (ISP)
 Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP) o Principio
de Responsabilidad Única
 “A class should have only one reason to change”

Single Responsibility Principle (SRP) o Principio
de Responsabilidad Única
 “Una clase debería tener una, y solo una razón para cambiar” Robert C. Martin
 Solo porque se puede hacer no significa que debas hacerlo.
 Clase con 2 o más responsabilidades: Responsabilidades acopladas.
 Entre más responsabilidades, más probabilidades de cambio.
 Alta cohesión, bajo acoplamiento.

Síntomas comunes SRP
 Código Spaguetti
 Clase dios
 Comentarios: “si”; “y”; ”pero”; “excepto”; “cuando”

¿Por qué usar SPR?
 Es más fácil re-utilizar partes del código.
 Las clases grandes son más difíciles de leer y cambiar.
 Solucionamos el dilema del nombre de la clase.

Open Closed Principle (OCP)
 “Todo módulo debe estar abierto para la extensión pero, cerrado para
modificación” Bertrand Meyer. Object Oriented Software Construction.
 Los cambios deben generar código nuevo,no modificar el código viejo.
 La clave está en la abstracción
 Strategy and Template method son las formas más comunes de satisfacer OCP.
 Si un cambio impacta varios módulos entonces la aplicación no esta bien diseñada.
 Afectar el comportamiento sin modificar.
 Debemos usar los miembros de la clase privados.
 Lo podemos lograr a través de abstracción, polimorfismo y herencia.

¿Se comportan igual? Ambos son caballos
en teoría.

Liskov Substitution Principle (LSP)

 “Si para todo objeto o1 de tipo S existe un objeto o2 de tipo T tal que para todo
programa P definido en función de T el comportamiento de P no cambia cuando
o1 es substituido por o2, entonces S es un subtipo de T” Barbara J. Liskov. Keynote
– Data .abstraction and hierarchy (1987).

 “Las funciones que usan punteros o referencias a clases base, deben ser capaces de
usar objetos de clases derivadas sin saberlo” Robert C. Martin.
 Si tenemos una clase BASE y dos subclases SUB1 y SUB2, el código cliente siempre
debe referirse a BASE. No debemos decir: SUB1 es una BASE.• En cambio decir:
SUB1 es reemplazable por una BASE.
 Si nuestra función recibe un animal, entonces podrá recibir un perro, un ratón o un
gato. Pero si requiere un Felino no podrá recibir un perro por ejemplo.
 Un cuadrado puede ser un rectángulo…pero el objeto cuadrado no es un objeto
rectángulo.

 Es la base de poder del polimorfismo.
 Los subtipos deben ser substituibles por sus tipos base.
 No podemos validar un modelo aisladamente. La validez depende del contexto
(sus clientes).
 La violación de LSP es una violación latente de OCP.
 Pensar en “Sustituible por” y no en “Es un”

Interface Segregation Principle (ISP)
 “Los clientes no deben ser forzados a depender de métodos que no usan.” Robert
C Martin.

¿Qué busca ISP?
 Evitar las interfaces “gordas”.
 A las interfaces gordas les falta de cohesión.
 No importa la cantidad de métodos, sino que todos sus clientes las utilicen.
 Síntoma: “Unimplemented method”.
 Inadvertidamente podemos acoplar clientes que usan ciertos métodos con otros
clientes que no los usan.

Dependency Inversion Principle (DIP)

 Módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben
depender de abstracciones.
 Abstracciones no deben depender de detalles. Los detalles deben depender de
abstracciones.
 Puede implementarse con:
 Inyección de dependencias
 IoC (Inversión del control)

 A) “Los módulos de alto nivel no deben dedepender de módulos de bajo nivel.
Ambosdeben depender de abstracciones.”
 B) “Las abstracciones no deben depender dedetalles. Los detalles deben depender
deabstracciones.”

 ¿ Por qué depender de una abstracción?
 El objeto cliente se desacopla de la implementación.
 Podemos intercambiar la implementación (OCP!!)
 Problemas dependencias directas:
 Las dependencias son transitivas
 Ventajas dependencias indirectas:
 Desacoplamiento.
 Aislamiento.
 Reusabilidad.

Para evitar dependencias
 loosely coupled: DIP
 highly cohesive: SRP
 easily composable: dependencias
 Context independent : dependencias
http://www.growing-object-oriented-software.com/

DRY- Don’t repeat yourself
 Evitar la repetición en todas sus posibilidades:
 No repetir código: funciones, métodos, clases, etc. → Reutilizar.
 No repetir librerías.
 No repetir documentación.

KISS- Keep it simple stupid!
 Nombres descriptivos (métodos, variables y clases).
 Los sistemas más eficaces son aquellos que mantienen la simplicidad evitando
complejidad innecesaria.
 Simplicidad es un objetivo del diseño, arquitectura y de la implementación.
 Se hace solo la funcionalidad requerida.
 No confundir con falta de características o funcionalidades incompletas.
 “La simplicidad es la máxima sofisticación”, Leonardo da Vinci.
 “Todo debe hacerse lo más simple posible, que no implica que sea lo más sencillo”,
Albert Einstein.
 “En igualdad de condiciones, la explicación más sencilla suele ser la correcta”, la navaja
de Ockham.

Bibliografía
 Posters motivacionales http://lostechies.com/derickbailey/2009/02/11/solid-
development-principles-in-motivational-pictures/
 PluralSight – SOLID Principles of Object Oriented Design http://www.pluralsight-
training.net/microsoft/Courses/TableOfContents?courseName=principles-oo- design
 Principios de DOO – Bob Martin
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
 Pablo’s SOLID Software Development http://lostechies.com/wp-
content/uploads/2011/03/pablos_solid_ebook.pdf
 Principios SOLID con ejemplos reales http://blog.gauffin.org/2012/05/solid-principles-
with-real-world-examples/
 From STUPID to SOLID Code! http://williamdurand.fr/2013/07/30/from-stupid-to-solid-
code/

Principios SOLID

Más contenido relacionado

La actualidad más candente

Similar a Principios SOLID

Más de Joan Sebastián Ramírez Pérez

Principios SOLID