Principios SOLID

1,330 views

Published on

Jornada de Arquitectura de Software - UTN FRRO - Rosario 11/06/2013

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,330
On SlideShare
0
From Embeds
0
Number of Embeds
162
Actions
Shares
0
Downloads
15
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Principios SOLID

  1. 1. Disertante: Ing. Rocco, SebastiánMail: srocco@movizen.comWeb: ww.movizen.comBlog: ww.srocco.com.arJornada de Arquitectura de SoftwarePrincipios SOLID
  2. 2. Agenda• ¿Qué diseño queremos?• Síntomas de un mal diseño.• Principios SOLID.• Comentarios finales.• Recursos adicionales.• Preguntas.
  3. 3. ¿Qué diseño queremos?• Cohesivo.• Robusto.• Flexible.• Reusable.• Mantenible.• Testeable.
  4. 4. Síntomas de un mal diseño• Rigidez.• Fragilidad.• Inmovilidad.• Viscosidad.• Complejidad innecesaria.• Repetición innecesaria.• Opacidad.
  5. 5. ¿Qué es SOLID?• Acrónimo mnemónico.• Introducido por Robert C. Martin a comienzosde la década del 2000.• Son cinco principios básicos de laprogramación orientada a objetos y el diseño.• Ayudan a desarrollar un software decalidad, legible, entendible y fácilmentetesteable.
  6. 6. Principios SOLIDSingle Responsibility Principle (SRP).Open Closed Principle (OCP).Liskov Substitution Principle (LSP).Interface Segregation Principle (ISP).Dependency Inversion Principle (DIP).
  7. 7. Principios SOLIDSRP: Principio de Responsabilidad Única.OCP: Principio Abierto-Cerrado.LSP: Principio de Substitución de Liskov.ISP: Principio de Segregación de Interfaces.DSI: Principio Inversión de Dependencia.
  8. 8. Responsabilidad única“Una clase debería tener una, y solo unarazón para cambiar”Robert C. MartinPrinciples of Object Oriented Design
  9. 9. Responsabilidad única• Clase con 2 o más responsabilidades:– Responsabilidades acopladas.• + responsabilidades, + probabilidades de cambio!• Síntomas:– Código spaghetti.– "God Class“.– Comentarios: “si”; “y”; ”pero”; “excepto”; “cuando”.• Ventajas:– 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.
  10. 10. Responsabilidad única
  11. 11. Responsabilidad única
  12. 12. Abierto-Cerrado“Todo módulo debe estar abierto para laextensión pero, cerrado para modificación”Bertrand MeyerObject Oriented Software Construction
  13. 13. Abierto-Cerrado• 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 formasmás comunes de satisfacer OCP.• Ningún diseño se puede cerrar a TODOS loscambios.
  14. 14. Abierto-Cerrado
  15. 15. Abierto-Cerrado
  16. 16. Substitución de Liskov“Si para todo objeto o1 de tipo S existe un objetoo2 de tipo T tal que para todo programa Pdefinido en función de T el comportamiento deP no cambia cuando o1 es substituido poro2, entonces S es un subtipo de T”Barbara J. LiskovKeynote – Data abstraction and hierarchy (1987)
  17. 17. Substitución de LiskovTraduciendo…“Las funciones que usan punteros o referenciasa clases base, deben ser capaces de usarobjetos de clases derivadas sin saberlo”Robert C. Martin
  18. 18. Substitución de Liskov• Es la base de poder del polimorfismo.• Los subtipos deben ser substituibles por sustipos base.• No podemos validar un modelo aisladamente.– La validez depende del contexto (sus clientes).• La violación de LSP es una violación latente deOCP
  19. 19. Substitución de Liskov
  20. 20. Substitución de Liskov• Un cuadrado puede ser un rectángulo….– Pero el objeto cuadrado NO es un objeto rectángulo.– El comportamiento no es igual!
  21. 21. Substitución de Liskov• Diseñar basándose en comportamientos• Pensar en “Sustituible por” y no en “Es un”-• Diseño por contrato:– Las pre-condiciones de los métodos de la sub-clase no deben ser más fuertes que las de la clasebase.– Las post-condiciones de los métodos de la sub-clase no deben ser más débiles que las de la clasebase.
  22. 22. Substitución de Liskov
  23. 23. Substitución de Liskov
  24. 24. Segregación de Interfaces“Los clientes no deben de ser forzados adepender de interfaces que no utilizan.”Robert C. Martin
  25. 25. Segregación de Interfaces• Apunta a evitar las interfaces “gordas”.• Les falta cohesión.• No importa la cantidad de métodos, sino quetodos sus clientes las utilicen.• Síntoma: “Unimplemented method”.• Inadvertidamente podemos acoplar clientesque usan ciertos métodos con otros clientesque no los usan.
  26. 26. Segregación de Interfaces
  27. 27. Segregación de Interfaces
  28. 28. Inversión de dependenciaA) “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.”
  29. 29. Inversión de dependencia• ¿ Por qué depender de una abstracción?– El objeto cliente se desacopla de laimplementación.– Podemos intercambiar la implementación (OCP!!)• Problemas dependencias directas:– ¡Las dependencias son transitivas!• Ventajas dependencias indirectas:– Desacoplamiento.– Aislamiento.– Reusabilidad.
  30. 30. Inversión de dependencia
  31. 31. Inversión de dependencia
  32. 32. SOLID - Comentarios Finales• Definen lineamientos, no son reglas estrictas.• Hay que comprender su motivación y aplicarloscon criterio.• No crear complejidad innecesaria!• No es posible escribir código perfecto…– TAMPOCO ES NECESARIO!• No gastar recursos donde no es necesario.• Con TDD, podemos refactorizar después!
  33. 33. SOLID - Comentarios Finales“El elemento más volátil en los proyectos softwareson los requisitos. Vivimos en un mundo derequisitos cambiantes, y nuestro trabajo es estarseguros de que nuestros software puede sobrevivira esos cambios, así que no culpes a los requisitoscambiantes por los fallos en el software.”Robert C. Martin
  34. 34. Recursos adicionales.
  35. 35. ¿Preguntas?
  36. 36. Muchas Gracias!
  37. 37. Datos de ContactoDisertante: Ing. Rocco, SebastiánMail: srocco@movizen.comWeb: ww.movizen.comBlog: www.srocco.com.ar

×