Este documento presenta los cinco principios SOLID para el desarrollo de software orientado a objetos: Single Responsibility Principle (un módulo debería tener una sola responsabilidad), Open Closed Principle (entidades de software deberían estar abiertas para extensión pero cerradas para modificación), Liskov Substitution Principle (funciones que usen clases base deben poder usar objetos de clases derivadas), Interface Segregation Principle (interfaces específicas son preferibles a interfaces generales), y Dependency Inversion Principle (módulos de alto nivel no deben depend

1. S.O.L.I.D.
¿Cómo lo aplico en mi código?

2. #codepassion_pe
@JuanjoFuchs @RaybertParedes

3. http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx

4. Que pasa
cuando nos
toca modificar
código?
http://www.albertelli.com/photoarchive/Random_2003/lawn_jenga0002.jpeg

5. Da miedo…
http://blog.rwbenwick.com/wp-content/uploads/2009/12/Reason-For-Leaving-iStock_000008369823Medium.jpg

6. http://www.albertelli.com/photoarchive/Random_2003/lawn_jenga0002.jpeg

7. Quien nos podrá ayudar?
Pues….
http://browse.deviantart.com/?qh=&section=&q=avengers#/d41k54l

8. Tampoco….
http://www.pharmatek.com/developers/developers.htm

9. Nosotros
http://www.catosplace.net/blogs/personal/wp-content/uploads/2011/04/developers.jpg

10. Pero como??
http://4.bp.blogspot.com/-wLWxI2BZTEo/TbP44yGHHXI/AAAAAAAACMA/ck1BVzrucHo/s1600/bg_doubt.jpg

11. Aprendiendo un poco de…
Etc…

12. En donde???
Y otros mas…

13. Bueno, manos a la ubre!!
Perdón, a la obra…. ;)

14. Entonces, ¿Qué es S.O.L.I.D.?
Es un acrónimo de:
• Siempre
• Olvido
• Lo
• Interesante del
• Desarrollo

15. Mentira, S.O.L.I.D. es un acrónimo de:
• Single Responsibility
• Open Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

17. Single Responsibility Principle
Una clase jamás debería tener más
de una razón por la cual cambiar
• Responsabilidad == Razón para cambiar
• Si una clase asume más de una
responsabilidad, entonces tendrá más de una
razón para cambiar.
• Acoplamiento de responsabilidades.

18. Single Responsibility Principle
Cohesión: Acoplamiento:
Qué tan fuertemente El grado en el cual cada
relacionadas y enfocadas están módulo de un programa
las distintas responsabilidades depende de cada uno de los
de un módulo. otros módulos

19. Single Responsibility Principle

20. Single Responsibility Principle

21. https://github.com/JuanjoFuchs/SOLID/tree/master/SRP
https://github.com/JuanjoFuchs/SOLID/tree/master/SRP%20-%20Refactorizado
Demo

23. Open Closed Principle
Entidades de software (clases, módulos,
funciones, etc.) deberían estar abiertas para
extensión pero cerradas para modificación.
• Si 1 cambio impacta a varios módulos,
entonces la aplicación no está bien diseñada.
• Debemos diseñar módulos que nunca
cambien

24. Open Closed Principle
Abiertas para extensión Cerradas para modificación
Podemos hacer que la No se necesita hacer cambios
aplicación se comporte de del código fuente de dicho
distintas formas. módulo.
Extendiendo el
comportamiento del módulo.
Pero cómo?
Abstracción

25. Open Closed Principle
https://gist.github.com/2896236#file_ocp_empleados.sin_refactorizar.cs

26. Open Closed Principle
https://gist.github.com/2896236#file_ocp_empleados.refactorizado.cs

27. https://github.com/JuanjoFuchs/SOLID/tree/master/OCP
https://github.com/JuanjoFuchs/SOLID/tree/master/OCP%20-%20Refactorizado
Demo

29. Liskov Substitution Principle
Funciones que usen punteros o referencias a
clases base deben poder usar objetos de clases
derivadas sin saberlo.
• Si tenemos una clase BASE y dos subclases
SUB1 y SUB2, el código cliente siempre debe
referirse a BASE.
• No decir: SUB1 es una BASE.
• En cambio decir: SUB1 es reemplazable por
una BASE.

30. Liskov Substitution Principle
https://gist.github.com/2896064 https://gist.github.com/2896078

31. https://github.com/JuanjoFuchs/SOLID/tree/master/LSP
Demo

33. Interface Segregation Principle
Los clientes no deberían estar forzados a
depender de interfaces que no utilizan.
• Las interfaces “gordas” o “contaminadas”
deben dividirse en varios grupos de funciones.
• Cada grupo será implementado por distintos
tipos de clientes.

34. Interface Segregation Principle
https://gist.github.com/2896112#file_lsp_animal.sin_refactorizar.cs

35. Interface Segregation Principle
https://gist.github.com/2896112#file_lsp_animal.refactorizado.cs

36. https://github.com/JuanjoFuchs/SOLID/tree/master/ISP
Demo

38. Dependency Inversion Principle
• 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)

39. DIP – Ejemplo 1
https://gist.github.com/2896132#file_dip_hola_mundo.sin_refactoriza https://gist.github.com/2896132#file_dip_hola_mundo.refactorizado.

40. DIP – Ejemplo 2
https://gist.github.com/2896132#file_dip_volvo.sin_refactorizar.cs https://gist.github.com/2896132#file_dip_volvo.refactorizado.cs

41. DIP – Arquitectura tradicional
UI
Negocio
Dependencia
Acceso a Datos Componentes

42. DIP – Arquitectura invertida
Acceso a Pruebas Web
UI
Datos Unitarias Services
Capa de Negocio
Entidades

43. https://github.com/JuanjoFuchs/SOLID/tree/master/DIP_Multicapa
https://github.com/JuanjoFuchs/SOLID/tree/master/DIP_Multicapa_Refactorizado
Demo

44. Referencias
• 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/

45. ¿Preguntas?