S.O.L.I.D.S.O.L.I.D.AltNetHispanoAltNetHispano

Carlos Peixhttp://carlospeix.com/

22

ProblemasProblemas

RigidezRigidez FragilidadFragilidad InmovilidadInmovilidad ViscosidadViscosidad Complejidad Complejidad

innecesariainnecesaria Repetición innecesariaRepetición innecesaria OpacidadOpacidad

33

Enfoque Agil/OODEnfoque Agil/OOD

Qué asumimos:Qué asumimos:– La única constante en el software es el cambio en La única constante en el software es el cambio en

los requerimientoslos requerimientos

Qué hacemos:Qué hacemos:– Detectar el problema siguiendo las metodologías Detectar el problema siguiendo las metodologías

ágileságiles– Diagnosticar aplicando principios de diseño (OOD)Diagnosticar aplicando principios de diseño (OOD)– Resolver mejorando el diseño, usando Resolver mejorando el diseño, usando

frecuentemente patrones como referenciafrecuentemente patrones como referencia

44

Principios SOLIDPrincipios SOLID

Responsabilidad únicaResponsabilidad única Abierto-CerradoAbierto-Cerrado Substitución de LiskovSubstitución de Liskov Inversión de Inversión de

dependenciadependencia Segregación de InterfazSegregación de Interfaz

55

Patrones y Principios SOLIDPatrones y Principios SOLID

Los patrones de diseño  (GoF) muestran, en Los patrones de diseño  (GoF) muestran, en alguna medida, uno o mas principios SOLID, alguna medida, uno o mas principios SOLID, aunque…aunque…

no hay relación directa entre los patrones de no hay relación directa entre los patrones de diseño (GoF) y los principios SOLID. Estos diseño (GoF) y los principios SOLID. Estos últimos son atributos que indican si un últimos son atributos que indican si un diseño es mejor o peor. diseño es mejor o peor.

Estos principios definen lineamientos, no son Estos principios definen lineamientos, no son reglas estrictas. Hay que comprender su reglas estrictas. Hay que comprender su motivación y aplicarlos con criterio. motivación y aplicarlos con criterio.

66

Responsabilidad únicaResponsabilidad única

Una clase debe tener una Una clase debe tener una única razón para ser cambiada.única razón para ser cambiada.

No es cierto que un elevado numero No es cierto que un elevado numero de clases pequeñas (o métodos de clases pequeñas (o métodos pequeños) sea mas difícil de entender. pequeños) sea mas difícil de entender. Siempre todo ese código estará ahí. Siempre todo ese código estará ahí.

77

Responsabilidad únicaResponsabilidad única

http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-posters.aspxposters.aspx

88

Abierto-CerradoAbierto-Cerrado

Las entidades de software (clases, Las entidades de software (clases, módulos, funciones, etc) deben estar módulos, funciones, etc) deben estar abiertas a extensión, pero cerradas a abiertas a extensión, pero cerradas a

modificación.modificación.

Acercarse a un idealAcercarse a un ideal

Los cambios deben generar código Los cambios deben generar código nuevonuevo,,no modificar el código no modificar el código viejoviejo..

99

Abierto-CerradoAbierto-Cerrado

http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-posters.aspxposters.aspx

1010

Substitución de LiskovSubstitución de Liskov

Los subtipos deben ser substituiblesLos subtipos deben ser substituiblespor sus tipos base.por sus tipos base.

Es la base de poder del polimorfismo.Es la base de poder del polimorfismo.

Cuidarse de typeof() y otros datos de tipo en runtime.Cuidarse de typeof() y otros datos de tipo en runtime.

1111

Substitución de LiskovSubstitución de Liskov

http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-posters.aspxposters.aspx

1212

Inversión de dependenciaInversión de dependencia

a)a) Los módulos de alto nivel no deben Los módulos de alto nivel no deben depender de los módulos de bajo nivel. depender de los módulos de bajo nivel. Ambos deben depender de abstracciones.Ambos deben depender de abstracciones.

b)b) Las abstracciones no deben depender de Las abstracciones no deben depender de detalles. Los detalles deben depender de detalles. Los detalles deben depender de las abstracciones.las abstracciones.

Es el principio general detrás del concepto Es el principio general detrás del concepto de Layers o Capas.de Layers o Capas.

1313

Inversión de dependenciaInversión de dependencia

http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-posters.aspxposters.aspx

1414

Dependencia de InterfacesDependencia de Interfaces

Responder a interfaces desacoplaResponder a interfaces desacopla La propiedad de la interfaz debe ser del clienteLa propiedad de la interfaz debe ser del cliente Principio de Hollywood: Principio de Hollywood:

“No nos llame, lo llamaremos”“No nos llame, lo llamaremos” Depender de abstracciones como ideal implica:Depender de abstracciones como ideal implica:

– Las variables no deben apuntar a clases concretasLas variables no deben apuntar a clases concretas– Las clases no deberían derivar de clases concretasLas clases no deberían derivar de clases concretas– Los métodos no deberían sobrescribir una implementación Los métodos no deberían sobrescribir una implementación

de su clase base.de su clase base. Cambiar las interfaces sólo si el cliente (su dueño) Cambiar las interfaces sólo si el cliente (su dueño)

lo necesita.lo necesita.

1515

Segregación de InterfazSegregación de Interfaz

Los clientes no deben ser forzados a depender Los clientes no deben ser forzados a depender de métodos que no usan.de métodos que no usan.

Apunta a evitar las interfaces “gordas”.Apunta a evitar las interfaces “gordas”.

No importa la cantidad de métodos, sino que todos No importa la cantidad de métodos, sino que todos sus clientes las utilicen.sus clientes las utilicen.

Inadvertidamente podemos Inadvertidamente podemos acoplar clientesacoplar clientes que usan que usan ciertos métodos con ciertos métodos con otros clientes otros clientes que no los usan.que no los usan.

1616

Segregación de InterfazSegregación de Interfaz

http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-posters.aspxposters.aspx

1717

PreguntaPreguntass??

Carlos Peixhttp://carlospeix.com/