solid - ¿cómo lo aplico a mi código?
Post on 27-Jun-2015
4.064 Views
Preview:
DESCRIPTION
TRANSCRIPT
S.O.L.I.D.¿Cómo lo aplico en mi código?
@JuanjoFuchs @RaybertParedes
#codepassion_pe
http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx
http://www.albertelli.com/photoarchive/Random_2003/lawn_jenga0002.jpeg
Que pasa cuando nos toca modificar código?
http://blog.rwbenwick.com/wp-content/uploads/2009/12/Reason-For-Leaving-iStock_000008369823Medium.jpg
Da miedo…
Porque probablemente esta sea nuestra única pieza por sacar
http://www.albertelli.com/photoarchive/Random_2003/lawn_jenga0002.jpeg
http://browse.deviantart.com/?qh=§ion=&q=avengers#/d41k54l
Quien nos podrá ayudar?
Pues….
Tampoco….http://www.pharmatek.com/developers/developers.htm
http://www.catosplace.net/blogs/personal/wp-content/uploads/2011/04/developers.jpg
Nosotros
Pero como??
http://4.bp.blogspot.com/-wLWxI2BZTEo/TbP44yGHHXI/AAAAAAAACMA/ck1BVzrucHo/s1600/bg_doubt.jpg
Etc…
Aprendiendo un poco de…
En donde???
Y otros mas…
Bueno, manos a la ubre!!
Perdón, a la obra…. ;)
Entonces, ¿Qué es S.O.L.I.D.?
Es un acrónimo de:• Siempre • Olvido• Lo • Interesante del• Desarrollo
Mentira, S.O.L.I.D. es un acrónimo de:
• Single Responsibility •Open Closed• Liskov Substitution• Interface Segregation•Dependency Inversion
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.
Single Responsibility Principle
Cohesión:
Qué tan fuertemente relacionadas y enfocadas están las distintas responsabilidades
de un módulo.
Acoplamiento:
El grado en el cual cada módulo de un programa
depende de cada uno de los otros módulos
Single Responsibility Principle
Single Responsibility Principle
Demo
https://github.com/JuanjoFuchs/SOLID/tree/master/SRP
https://github.com/JuanjoFuchs/SOLID/tree/master/SRP%20-%20Refactorizado
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
Open Closed Principle
Abiertas para extensión
Podemos hacer que la aplicación se comporte de
distintas formas.
Extendiendo el comportamiento del módulo.
Cerradas para modificación
No se necesita hacer cambios del código fuente de dicho
módulo.
AbstracciónPero cómo?
Open Closed Principle
https://gist.github.com/2896236#file_ocp_empleados.sin_refactorizar.cs
Open Closed Principle
https://gist.github.com/2896236#file_ocp_empleados.refactorizado.cs
Demo
https://github.com/JuanjoFuchs/SOLID/tree/master/OCP
https://github.com/JuanjoFuchs/SOLID/tree/master/OCP%20-%20Refactorizado
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.
Liskov Substitution Principle
https://gist.github.com/2896064 https://gist.github.com/2896078
Demo
https://github.com/JuanjoFuchs/SOLID/tree/master/LSP
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.
Interface Segregation Principle
https://gist.github.com/2896112#file_lsp_animal.sin_refactorizar.cs
Interface Segregation Principle
https://gist.github.com/2896112#file_lsp_animal.refactorizado.cs
Demo
https://github.com/JuanjoFuchs/SOLID/tree/master/ISP
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)
DIP – Ejemplo 1
https://gist.github.com/2896132#file_dip_hola_mundo.sin_refactorizar.cs
https://gist.github.com/2896132#file_dip_hola_mundo.refactorizado.cs
DIP – Ejemplo 2
https://gist.github.com/2896132#file_dip_volvo.sin_refactorizar.cs https://gist.github.com/2896132#file_dip_volvo.refactorizado.cs
DIP – Arquitectura tradicional
UI
Negocio
Acceso a Datos Componentes Dep
ende
ncia
DIP – Arquitectura invertida
Acceso a Datos UI Pruebas
UnitariasWeb
Services
Capa de Negocio
Entidades
Demo
https://github.com/JuanjoFuchs/SOLID/tree/master/DIP_Multicapa_Refactorizado
https://github.com/JuanjoFuchs/SOLID/tree/master/DIP_Multicapa
Referencias• Posters motivacionales
http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
• PluralSight – SOLID Principles of Object Oriented Designhttp://www.pluralsight-training.net/microsoft/Courses/TableOfContents?courseName=principles-oo-design
• Principios de DOO – Bob Martinhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• Pablo’s SOLID Software Developmenthttp://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdf
• Principios SOLID con ejemplos realeshttp://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/
¿Preguntas?
top related