Principios SOLID

Principios de diseño orientado a objetosJoan Sebastián Ramírez Pérez2015

Agenda

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

¿Qué diseño queremos?

Cohesivo Robusto Reusable Flexible Mantenible Testeable

¿Y si no cumplimos?

¿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.

Ejemplo


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/

Arquitectura DIP

Ejemplos

Agenda


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.

Agenda


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.

Agenda


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/

http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/



http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

http://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdf

http://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdf

http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/

http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/

http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/

http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/

Principios SOLID

Software

Transcript of Principios SOLID