principios solid
TRANSCRIPT
Principios de diseño orientado a objetosJoan Sebastián Ramírez Pérez2015
Agenda
¿Qué diseño queremos? SOLID DRY KISS Bibliografía
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)
Liskov Substitution Principle (LSP)
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).
Liskov Substitution Principle (LSP)
“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
Liskov Substitution Principle (LSP)
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)
Dependency Inversion Principle (DIP)
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)
Dependency Inversion Principle (DIP)
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.”
Dependency Inversion Principle (DIP)
¿ 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
Ejemplos
Agenda
¿Qué diseño queremos? SOLID DRY KISS Bibliografía
DRY
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
¿Qué diseño queremos? SOLID DRY KISS Bibliografía
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.
KISS
KISS
Agenda
¿Qué diseño queremos? SOLID DRY KISS Bibliografía
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/