Principios SOLID de Diseño Orientado a Objetos
Upcoming SlideShare
Loading in...5
×
 

Principios SOLID de Diseño Orientado a Objetos

on

  • 3,816 views

 

Statistics

Views

Total Views
3,816
Views on SlideShare
3,816
Embed Views
0

Actions

Likes
1
Downloads
94
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Principios SOLID de Diseño Orientado a Objetos Principios SOLID de Diseño Orientado a Objetos Presentation Transcript

  • 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?
  • ¿Cómo hacemos software?
    Empezamos…
  • ¿Cómo hacemos software?
    Se empieza a usar…
  • ¿Cómo hacemos software?
    Tienes que hacer cambios…
    SayWhat?
  • ¿Cómo hacemos software?
    Luego… nuevos cambios…
  • ¿Cómo hacemos software?
    Y más…. y más cambios…
  • ¿Cómo hacemos software?
    Encuentras solución…
  • ¿Cómo hacemos software?
    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…
  • Aquí huele raro…
  • Aquí huele raro…
  • 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 ejemplo
    Las políticas de alto y bajo nivel dependen de abstracciones.
  • SOLID
    ¿Qué es eso?
  • SOLID
    ¿Qué es eso?
    Single ResponsibilityPrinciple
    Open ClosedPrinciple
    LiskovSubstitutionPrinciple
    Interface SegregationPrinciple
    DependencyInversionPrinciple
  • Single ResponsibilityPrinciple
    ¿Qué hace este código?
  • Single ResponsibilityPrinciple
  • Single ResponsibilityPrinciple
    “Una clase debería tener una, y solo una
    razón para cambiar”
    Robert C. Martin
    Principles of Object Oriented Design
  • Single ResponsibilityPrinciple
  • Single ResponsibilityPrinciple
  • Single ResponsibilityPrinciple
    ¿Que hay del encapsulamiento?
    ¿No debería de saber como se salva a si mismo?
    ¿?
  • SOLID
    ¿Qué es eso?
    Single ResponsibilityPrinciple
    Open ClosedPrinciple
    LiskovSubstitutionPrinciple
    Interface SegregationPrinciple
    DependencyInversionPrinciple
  • Open-ClosedPrinciple
    “Todo módulo debe estar abierto para la extensión pero, cerrado para modificación”
    Bertrand Meyer
    ObjectOriented Software Construction
  • Open-ClosedPrinciple
    ¿Qué quiere decir esto?
    Afectar el comportamiento, sin modificar.
  • Open-ClosedPrinciple
    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?
  • Open-ClosedPrinciple
    Cerrado para modificación:
    No se puede modificar el código de lo que hay.
  • Open-ClosedPrinciple
  • Open-ClosedPrinciple
    ¿Qué podemos hacer para resolverlo?
    Abstracción.
  • Open-ClosedPrinciple
  • Open-ClosedPrinciple
    Ejemplo Shapes 01
  • Open-ClosedPrinciple
    Ejemplo Shapes 02
  • Open-ClosedPrinciple
    ¿Es posible cerrar una clase al 100%?
  • Open-ClosedPrinciple
    ¿Cómo resolver el problema si queremos pintar los círculos antes que los rectángulos?
  • Open-ClosedPrinciple
    ¿Y si el orden no depende del tipo de la figura?
  • Open-ClosedPrinciple
    ¿Consejos para evitar romper este principio?
    Heurísticas para hacer esto posible:
    Hacer las variables miembro privadas.
  • Open-ClosedPrinciple
  • Open-ClosedPrinciple
    ¿Consejos para evitar romper este principio?
    Heurísticas para hacer esto posible:
    Hacer las variables miembro privadas.
    No tener variables globales. Nunca.
  • Open-ClosedPrinciple
  • Open-ClosedPrinciple
    ¿Consejos para evitar romper este principio?
    Heurísticas para hacer esto posible:
    Hacer las variables miembro privadas.
    No tener variables globales. Nunca.
    Evitar usar RTTI.
  • Open-ClosedPrinciple
  • 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?
    Single ResponsibilityPrinciple
    Open ClosedPrinciple
    LiskovSubstitutionPrinciple
    Interface SegregationPrinciple
    DependencyInversionPrinciple
  • LiskovSubstitutionPrinciple
    “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. Liskov
    Keynote – Data abstraction and hierarchy (1987)
  • LiskovSubstitutionPrinciple
  • LiskovSubstitutionPrinciple
    Traduciendo…
    “Las funciones que usan punteros o referencias a clases base, deben ser capaces de usar objetos de clases derivadas sin saberlo”
  • LiskovSubstitutionPrinciple
  • LiskovSubstitutionPrinciple
    [Otro ejemplo sutil de violación del LSP]
    [código LSP]
  • LiskovSubstitutionPrinciple
    [El problema real LSP]
    [código LSP]
  • LiskovSubstitutionPrinciple
    ¿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.
  • LiskovSubstitutionPrinciple
    ¿Qué fue mal?
    Para que el “Open ClosedPrinciple” se mantenga todas las clases derivadas deben adherirse al comportamiento que el cliente espera.
  • LiskovSubstitutionPrinciple
    Designbycontract ™
    (diseño por contrato)
    Precondiciones
    Post condiciones
    Invariantes
  • LiskovSubstitutionPrinciple
    Designbycontract
    Derivando, solo se puede remplazar:
    Precondición: por una más débil.
    Post condición: por una más fuerte.
  • LiskovSubstitutionPrinciple
  • LiskovSubstitutionPrinciple
    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 sean PersistentObject
  • LiskovSubstitutionPrinciple
  • LiskovSubstitutionPrinciple
    Solución problemática:
    Conoce el tipo.
    Falla con una excepción en tiempo de ejecución.
  • LiskovSubstitutionPrinciple
  • LiskovSubstitutionPrinciple
    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.
  • LiskovSubstitutionPrinciple
  • LiskovSubstitutionPrinciple
    Solución usando LSP:
    Transparente
    Menos restrictiva
    Inherente a la estructura del código
  • LiskovSubstitutionPrinciple
    LSP es parte fundamental del Open ClosedPrinciple.
  • SOLID
    ¿Qué es eso?
    Single ResponsibilityPrinciple
    Open ClosedPrinciple
    LiskovSubstitutionPrinciple
    Interface SegregationPrinciple
    DependencyInversionPrinciple
  • DependencyInversionPrinciple
    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.”
  • DependencyInversionPrinciple
    ¿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.
  • DependencyInversionPrinciple
  • DependencyInversionPrinciple
    ¡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.
  • DependencyInversionPrinciple
    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 Booch
    ObjectSolution (1996)
  • DependencyInversionPrinciple
    Interpretación (?)
  • DependencyInversionPrinciple
    Análisis
    Implicaciones de estas dependencias directas:
    ¡Las dependencias son transitivas!
    Cambios en las capas inferiores son susceptibles a propagarse.
    Es difícil reutilizar las capas superiores.
  • DependencyInversionPrinciple
    Interpretación
  • DependencyInversionPrinciple
    Análisis
    Implicaciones de estas dependencias indirectas:
    Desacoplo.
    Aislamiento.
    Reusabilidad.
    Estabilidad.
  • DependencyInversionPrinciple
  • DependencyInversionPrinciple
  • DependencyInversionPrinciple
  • DependencyInversionPrinciple
  • DependencyInversionPrinciple
    Indispensable para implementación de frameworks.
    Resistente al cambio
    Abstracción y detalle están aislados uno del otro, por lo que aumenta la mantenibilidad.
  • SOLID
    ¿Qué es eso?
    Single ResponsibilityPrinciple
    Open ClosedPrinciple
    LiskovSubstitutionPrinciple
    Interface SegregationPrinciple
    DependencyInversionPrinciple
  • Interface SegregationPrinciple
    Sabemos cómo manejar la complejidad del código. Pero…
    A medida que el código crece…
  • Interface SegregationPrinciple
    Las interfaces también crecen…
  • Interface SegregationPrinciple
    Fat interfaces
    (Interfaces gordas)
    Les falta cohesión.
    Pueden separarse en grupos donde cada grupo sirve a un conjunto diferente de clientes.
  • Interface SegregationPrinciple
  • Interface SegregationPrinciple
    Fat interfaces
    (Interfaces gordas)
    Estas interfaces se necesitan.
    Pero… !No todas en una sola clase!
  • Interface SegregationPrinciple
    Fat interfaces
    (Interfaces gordas)
    ¿De donde salen?
  • Interface SegregationPrinciple
  • Interface SegregationPrinciple
  • Interface SegregationPrinciple
    Clientes separados implican interfaces separadas.
  • Interface SegregationPrinciple
    ¿Por qué?
    Los clientes ejercen fuerzas sobre las interfaces que emplean.
  • Interface SegregationPrinciple
    ¿Cuáles son?
  • Interface SegregationPrinciple
  • Interface SegregationPrinciple
  • Interface SegregationPrinciple
    Implicaciones de estos cambios.
  • Interface SegregationPrinciple
    “Los clientes no deben de ser forzados a depender de interfaces que no utilizan.”
    Robert C. Martin
  • Interface SegregationPrinciple
    ¿Qué hacemos entonces?
  • Interface SegregationPrinciple
  • Interface SegregationPrinciple
  • 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.com
    www.google.com
    Patterns and AdvancedPrinciples of OOD (R.Martin)
    ObjectOriented Software Construction
    (B. Meyer)
    ObjectOrientedAnalysis and Design
    (G. Booch)