Principios SOLID de Diseño Orientado a Objetos

Principios SOLID de Programación Orientada a Objetos

¿Diseño Orientado a Objetos?

¿Qué es? ¿De qué trata?

¿Diseño Orientado a Objetos?

Separación de responsabilidades.Encapsulamiento.Manejo de dependencias.

¿Cómo hacemos software?

¿Qué va mal en esta historia?


Empezamos…


Se empieza a usar…


Tienes que hacer cambios…

Say What?


Luego… nuevos cambios…


Y más…. y más cambios…


Encuentras solución…


Este código se está pudriendo…

Aquí huele raro…

¿Cuándo sabes que comienza a podrirse?

Rezas para que no tengas que hacer cambios.Cambios “sencillos” toman semanas…Trabajar con el código es una tortura…Etc.

Aquí huele raro…

¿Por qué?

Rigidez: Tantas interdependencias que un cambio implica cambios por todas partes.

Fragilidad: El sistema se rompe fácilmente, y en lugares que no relacionados.

Aquí huele raro…

¿Por qué?

Movilidad: El código no es reusable.

Viscosidad: En sus dos vertientes, diseño y entorno.

Aquí huele raro…

¿ok… pero… cómo sucede?

Aquí huele raro…

¡El código crece!

Aquí huele raro…

Y si no se mantiene adecuadamente…

Aquí huele raro…

Se hecha a perder…

Aquí huele raro…

Comparación

¿Cuáles son las diferencias?Primer ejemplo

Las políticas de alto nivel dependen directamente de las de bajo nivel.

Segundo ejemploLas políticas de alto y bajo nivel dependen de abstracciones.

SOLID

¿Qué es eso?

SOLID

¿Qué es eso?

Single Responsibility PrincipleOpen Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

Single Responsibility Principle

¿Qué hace este código?


“Una clase debería tener una, y solo una razón para cambiar”

Robert C. MartinPrinciples of Object Oriented Design


¿Que hay del encapsulamiento?

¿No debería de saber como se salva a si mismo?

¿?

SOLID

¿Qué es eso?


Open-Closed Principle

“Todo módulo debe estar abierto para la extensión pero, cerrado para

modificación”

Bertrand MeyerObject Oriented Software Construction


¿Qué quiere decir esto?

Afectar el comportamiento, sin modificar.


Abierto para extensión:¿Cómo podemos hacerlo comportarse en nuevas y distintas formas a medida que la aplicación evoluciona, o para ajustarse a las necesidades de nuevas aplicaciones?


Cerrado para modificación:No se puede modificar el código de lo que hay.


¿Qué podemos hacer para resolverlo?

Abstracción.


Ejemplo Shapes 01


Ejemplo Shapes 02


¿Es posible cerrar una clase al 100%?


¿Cómo resolver el problema si queremos pintar los círculos antes que los

rectángulos?


¿Y si el orden no depende del tipo de la figura?


¿Consejos para evitar romper este principio?

Heurísticas para hacer esto posible:Hacer las variables miembro

privadas.




privadas.No tener variables globales.

Nunca.




privadas.No tener variables globales.

Nunca.Evitar usar RTTI.

SOLID

Herramientas bases para lograr mantenibilidad:

Abstracción.Herencia.Polimorfismo.

SOLID

Pero… ¿Qué reglas siguen?¿Qué características tienen en

común?¿Qué problemas nos podemos

encontrar?

SOLID

¿Qué es eso?


Liskov Substitution Principle

“Si para todo objeto o1 de tipo S existe un objeto o2 de tipo T tal que para todo

programa P definido en función de T el comportamiento de P no cambia cuando o1 es substituido por o2, entonces S es un

subtipo de T”

Barbara J. LiskovKeynote – Data abstraction and hierarchy (1987)


Traduciendo…

“Las funciones que usan punteros o referencias a clases base, deben ser capaces de usar objetos de clases

derivadas sin saberlo”


[Otro ejemplo sutil de violación del LSP][código LSP]


[El problema real LSP][código LSP]


¿Qué fue mal?

El programador hizo suposiciones.Square no se comporta como Rectangle.La relación “es un” se refiere al compor-tamiento extrínseco, no intrínseco.


¿Qué fue mal?

Para que el “Open Closed Principle” se mantenga todas las clases derivadas deben adherirse al comportamiento que el cliente espera.


Design by contract ™(diseño por contrato)

PrecondicionesPost condicionesInvariantes


Design by contract

Derivando, solo se puede remplazar:Precondición: por una más débil.Post condición: por una más

fuerte.


El problema:Añadir PersistentSet que se puede

leer y escribir de un stream, pero…Condiciones:

Usar librería de tercero.Requiere que los objetos internos

seanPersistentObject


Solución problemática:Conoce el tipo.Falla con una excepción en tiempo de ejecución.


Solución que no se adhiere a LSP:Es una convención.Es fácil de violar.No funciona del todo (el nuevo). Hay que revenderla.Es restrictiva.


Solución usando LSP:TransparenteMenos restrictivaInherente a la estructura del

código


LSP es parte fundamental del Open Closed Principle.

SOLID

¿Qué es eso?


Dependency Inversion Principle

A) “Los módulos de alto nivel no deben de depender de módulos de bajo nivel. Ambos deben depender de abstracciones.”

B) “Las abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones.”


¿Por qué “inversión”?

Las formas mas tradicionales de diseño de software como el diseño y análisis estructurado, promueven la creación de estructuras donde los módulos de alto nivel dependen sobre módulos de bajo nivel.


¡Es absurdo! … ¿Pero… por qué?

Lo que queremos es la reutilización de los módulos de alto nivel.

Los módulos de bajo nivel ya sabemos re-utilizarlos.


El concepto de capas (Layering)

“… toda arquitectura orientado a objetos que esté bien estructurada tiene capas claramente definidas, donde cada capa ofrece una serie de servicios coherentes mediante una serie de interfaces bien controladas y definidas.”

Grady BoochObject Solution (1996)


Interpretación (?)


AnálisisImplicaciones de estas dependencias directas:

¡Las dependencias son transitivas!Cambios en las capas inferiores

son susceptibles a propagarse.Es difícil reutilizar las capas

superiores.


Interpretación


AnálisisImplicaciones de estas dependencias indirectas:

Desacoplo.Aislamiento.Reusabilidad.Estabilidad.


Indispensable para implementación de frameworks.Resistente al cambioAbstracción y detalle están aislados uno del otro, por lo que aumenta la mantenibilidad.

SOLID

¿Qué es eso?


Interface Segregation Principle

Sabemos cómo manejar la complejidad del código. Pero…

A medida que el código crece…


Las interfaces también crecen…


Fat interfaces(Interfaces gordas)

Les falta cohesión.Pueden separarse en grupos donde cada grupo sirve a un conjunto diferente de clientes.



Estas interfaces se necesitan.Pero… !No todas en una sola clase!



¿De donde salen?


Clientes separados implican interfaces separadas.


¿Por qué?

Los clientes ejercen fuerzas sobre las interfaces que emplean.


¿Cuáles son?


Implicaciones de estos cambios.


“Los clientes no deben de ser forzados a depender de interfaces que no

utilizan.”

Robert C. Martin


¿Qué hacemos entonces?

SOLID

Por último…

Son principios, no leyes. Hay que conocerlos y entenderlos para saber utilizarlos apropiadamente.

Todos deberíamos de aplicarlos.

SOLID

Por último…

Es la única forma de disminuir el número de programadores que cometen suicidio.

SOLID

¿Donde aprender más?

www.objectmentor.comwww.google.com

Patterns and Advanced Principles of OOD (R.Martin)Object Oriented Software Construction

(B. Meyer)Object Oriented Analysis and Design

(G. Booch)

http://www.objectmentor.com/

http://www.google.com/

Principios SOLID de Diseño Orientado a Objetos

Documents

Transcript of Principios SOLID de Diseño Orientado a Objetos