SOLID - ¿Cómo lo aplico a mi código?

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=&section=&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?