0
Principios SOLID<br />Martín Salías<br />
Decadencia del software<br />Rigidez<br />Fragilidad<br />Inmovilidad<br />Viscosidad<br />Complejidad innecesaria<br />Re...
Newsgroups: comp.object<br />From: rmar...@rcmcon.com (Robert Martin)<br />Date: Thu, 16 Mar 1995 15:12:00 GMT<br />Subjec...
Single Responsibility<br />Open-Closed<br />Liskov Substitution<br />Interface Segregation<br />Dependency Inversion<br />
Responsabilidad única<br />Abierto-Cerrado<br />Substitución de Liskov<br />Segregación de Interfaz<br />Inversión de Depe...
Unaclasedebetener un únicoeje de cambio.<br />
Responsabilidad única<br />Una clase debe tener una única razón para ser cambiada.<br />Responsabilidad = Eje de cambios<b...
Dos responsabilidades<br />MyRectangle<br />Aplicación<br />Geométrica<br />Aplicación<br />Gráfica<br />+ Draw()<br />+ A...
Deslindando responsabilidades<br />Aplicación<br />Gráfica<br />Aplicación<br />Gráfica<br />Aplicación<br />Geométrica<br...
Se debepoder extender el comportamiento sin modificarlo.<br />
Abierto-Cerrado<br />Las entidades de software (clases, módulos, funciones, etc) deben estar abiertas a extensión, pero ce...
Cerrando a modificaciones<br />El cliente está abierto <br />a modificaciones.<br />Servidor<br />Cliente<br /><<Interfaz>...
Cerrando a modificaciones<br />Política<br />Patrón Template Method:<br />La clase base está cerradaa modificaciones.<br /...
Las clasesderivadasdebenpodersustituírseporsus bases.<br />
Substitución de Liskov<br />Los subtipos deben ser substituiblespor sus tipos base.<br />     Si para cada objeto o1 de ti...
Implicancias del LSP<br />La validez depende del contexto<br />No podemos validar un modelo aisladamente<br />Diseñar basá...
Diseño por contrato<br />Preservar las invariantes<br />Pre y pos-condiciones<br />La redeclaración de una rutina (en una ...
Un ejemplo más complejo (1)<br />Lista<br />Librería<br />Listailimitada<br />Listailimitada<br />Listalimitada<br />Lista...
Un ejemplo más complejo (2)<br />Lista<br />Librería<br />Listapersistente<br />Listapersistente<br />Listapersistente<br />
Un ejemplo más complejo (3)<br />Contenedor<br />Librería<br />Quitar(T)<br />Existe(T)<br />Listapersistente<br />Listape...
Produzca interfaces de granofinoespecíficaspara un cliente.<br />
Segregación de Interfaz<br />   Los clientes no deben ser forzados a depender de métodos que no usan.<br />Apunta a evitar...
Una interfaz engorda<br />Timer<br /><<interface>><br />Cliente Timer<br />+ TimeOut()<br />Puerta<br />+ Trabar()<br />+ ...
Separación por delegación<br />Timer<br /><<interface>><br />Cliente Timer<br />+ TimeOut()<br />Puerta<br />Puerta tempor...
Separación por herencia múltiple<br />Timer<br /><<interface>><br />Cliente Timer<br />Puerta<br />+ TimeOut()<br />Puerta...
Dependa de abstracciones, no de concreciones.<br />
Inversión de dependencia<br />Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depend...
Capas acopladas<br />CapaPolítica<br />CapaMecanismo<br />CapaUtilidad<br />
Capas desacopladas<br />Política<br />CapaPolítica<br /><<interface>><br />Servicio depolíticas<br />Mecanismo<br />CapaMe...
Recursos<br />Artículo del Tío Bob sobrediseño OOhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />
Bibliografíaadicional<br />Matt Weisfeld <br />Bertrand Meyer<br />Rebecca Wirfs-Brock <br />Scott Ambler<br />John Hunt<b...
martin@salias.com.ar<br />@MartinSalias<br />http://CodeAndBeyond.org<br />
Upcoming SlideShare
Loading in...5
×

Solid Principles

1,388

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,388
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • SOLID principles5 principios rectores de OOD; la base de los patrones de diseño¿una novedad? -&gt; NO
  • Rigidez: difícil de cambiarFragilidad: fácil de romperInmovilidad: difícil de reutilizarViscosidad: difícil de modificar correctamenteEn el diseño mismoEn el ambiente (compilación, control de fuentes, herramientas que no favorecen una buena manera de hacer las cosas; o la carencia de aquellas que la facilitan).Complejidad: sobre-diseño ó sobre-arquitectura; exceso de especulaciónRepetición: exceso de “copy/paste development”Opacidad: falta total de expresividad= Sample: TheCopyProgram
  • Transcript of "Solid Principles"

    1. 1.
    2. 2. Principios SOLID<br />Martín Salías<br />
    3. 3. Decadencia del software<br />Rigidez<br />Fragilidad<br />Inmovilidad<br />Viscosidad<br />Complejidad innecesaria<br />Repetición innecesaria<br />Opacidad<br />
    4. 4. Newsgroups: comp.object<br />From: rmar...@rcmcon.com (Robert Martin)<br />Date: Thu, 16 Mar 1995 15:12:00 GMT<br />Subject: Re: The Ten Commandments of OO Programming<br />---<br />If I had to write commandments, these would be candidates. <br />1. Software entities (classes, modules, etc) should be open for extension, but closed for modification. (The open/closed principle -- Bertrand Meyer) <br />2. Derived classes must usable through the base class interface without the need for the user to know the difference. (The Liskov Substitution Principle) <br />3. Details should depend upon abstractions. Abstractions should not depend upon details. (Principle of Dependency Inversion) <br />4. The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused. <br />5. Classes within a released component should share common closure. That is, if one needs to be changed, they all are likely to need to be changed. What affects one, affects all. <br />6. Classes within a released component should be reused together. That is, it is impossible to separate the components from each other in order to reuse less than the total. <br />7. The dependency structure for released components must be a DAG. There can be no cycles. <br />8. Dependencies between released components must run in the direction of stability. The dependee must be more stable than the depender. <br />9. The more stable a released component is, the more it must consist of abstract classes. A completely stable component should consist of nothing but abstract classes. <br />10. Where possible, use proven patterns to solve design problems. <br />11. When crossing between two different paradigms, build an interface layer that separates the two. Don't pollute one side with the paradigm of the other.<br />
    5. 5. Single Responsibility<br />Open-Closed<br />Liskov Substitution<br />Interface Segregation<br />Dependency Inversion<br />
    6. 6. Responsabilidad única<br />Abierto-Cerrado<br />Substitución de Liskov<br />Segregación de Interfaz<br />Inversión de Dependencia<br />
    7. 7. Unaclasedebetener un únicoeje de cambio.<br />
    8. 8. Responsabilidad única<br />Una clase debe tener una única razón para ser cambiada.<br />Responsabilidad = Eje de cambios<br />(SI el cambio sucede)<br />Recibir el primer golpe<br />
    9. 9. Dos responsabilidades<br />MyRectangle<br />Aplicación<br />Geométrica<br />Aplicación<br />Gráfica<br />+ Draw()<br />+ Area() : double<br />GUI<br />
    10. 10. Deslindando responsabilidades<br />Aplicación<br />Gráfica<br />Aplicación<br />Gráfica<br />Aplicación<br />Geométrica<br />Aplicación<br />Geométrica<br />Aplicación<br />Geométrica<br />Aplicación<br />Geométrica<br />GeoRectangle<br />GraphRectangle<br />+ Area() : double<br />+ Draw()<br />GUI<br />
    11. 11. Se debepoder extender el comportamiento sin modificarlo.<br />
    12. 12. Abierto-Cerrado<br />Las entidades de software (clases, módulos, funciones, etc) deben estar abiertas a extensión, pero cerradas a modificación.<br />Acercarse a un ideal<br />Los cambios deben generar código nuevo,no modificar el código viejo.<br />
    13. 13. Cerrando a modificaciones<br />El cliente está abierto <br />a modificaciones.<br />Servidor<br />Cliente<br /><<Interfaz>><br />ICliente<br />Cliente<br />Patrón Strategy: <br />El cliente está abierto<br />y cerrado.<br />Servidor<br />
    14. 14. Cerrando a modificaciones<br />Política<br />Patrón Template Method:<br />La clase base está cerradaa modificaciones.<br />+ ReglaPolitica()<br />- Servicio()<br />Implementación<br />La implementación delmétodo lo abre a cuantasextensiones se necesiten.<br />- Servicio()<br />
    15. 15. Las clasesderivadasdebenpodersustituírseporsus bases.<br />
    16. 16. Substitución de Liskov<br />Los subtipos deben ser substituiblespor sus tipos base.<br /> Si para cada objeto o1 de tipo S hay un objeto o2 de tipo T tal que para todo programa P definido en términos de T, el comportamiento de P no varía cuando o1 es sustitido por o2, entonces S es un subtipo de T.<br />Es la base de poder del polimorfismo.<br />Cuidarse de GetType() y otros datos de tipo en runtime.<br />
    17. 17. Implicancias del LSP<br />La validez depende del contexto<br />No podemos validar un modelo aisladamente<br />Diseñar basándose en comportamientos<br />Presunciones razonables (¿cómo acotarlas?)<br />
    18. 18. Diseño por contrato<br />Preservar las invariantes<br />Pre y pos-condiciones<br />La redeclaración de una rutina (en una derivación) debe solamente reemplazar la precondición original con una igual o más débil, y la poscondición original con una igual o más fuerte.<br />Eiffel soporta nativamente DBC<br />En .NET ó Java usamos Unit Tests<br />Soporte incipiente en .NET 4<br />
    19. 19. Un ejemplo más complejo (1)<br />Lista<br />Librería<br />Listailimitada<br />Listailimitada<br />Listalimitada<br />Listalimitada<br />
    20. 20. Un ejemplo más complejo (2)<br />Lista<br />Librería<br />Listapersistente<br />Listapersistente<br />Listapersistente<br />
    21. 21. Un ejemplo más complejo (3)<br />Contenedor<br />Librería<br />Quitar(T)<br />Existe(T)<br />Listapersistente<br />Listapersistente<br />Lista<br />ListaPersistente<br />Agregar(T)<br />Agregar(T)<br />
    22. 22. Produzca interfaces de granofinoespecíficaspara un cliente.<br />
    23. 23. Segregación de Interfaz<br /> Los clientes no deben ser forzados a depender de métodos que no usan.<br />Apunta a evitar las interfaces “gordas”.<br />No importa la cantidad de métodos, sino que todos sus clientes las utilicen.<br />Inadvertidamente podemos acoplar clientes que usan ciertos métodos con otros clientes que no los usan.<br />
    24. 24. Una interfaz engorda<br />Timer<br /><<interface>><br />Cliente Timer<br />+ TimeOut()<br />Puerta<br />+ Trabar()<br />+ Destrabar()<br />+ Abierta()<br />Puerta<br />Puerta temporizada<br />
    25. 25. Separación por delegación<br />Timer<br /><<interface>><br />Cliente Timer<br />+ TimeOut()<br />Puerta<br />Puerta temporizada<br />Adapter Puerta <br />Temporizada<br />+ TimeOut()<br />+ TimeOutPuerta()<br /><<instancia>><br />
    26. 26. Separación por herencia múltiple<br />Timer<br /><<interface>><br />Cliente Timer<br />Puerta<br />+ TimeOut()<br />Puerta <br />Temporizada<br />+ TimeOut()<br />
    27. 27. Dependa de abstracciones, no de concreciones.<br />
    28. 28. Inversión de dependencia<br />Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de abstracciones.<br />Las abstracciones no deben depender de detalles. Los detalles deben depender de las abstracciones.<br /> Es el principio general detrás del concepto de Layers o Capas.<br />
    29. 29. Capas acopladas<br />CapaPolítica<br />CapaMecanismo<br />CapaUtilidad<br />
    30. 30. Capas desacopladas<br />Política<br />CapaPolítica<br /><<interface>><br />Servicio depolíticas<br />Mecanismo<br />CapaMecanismo<br /><<interface>><br />Servicio demecanismos<br />Utilidad<br />CapaUtilidad<br />
    31. 31. Recursos<br />Artículo del Tío Bob sobrediseño OOhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />
    32. 32. Bibliografíaadicional<br />Matt Weisfeld <br />Bertrand Meyer<br />Rebecca Wirfs-Brock <br />Scott Ambler<br />John Hunt<br />David West<br />
    33. 33. martin@salias.com.ar<br />@MartinSalias<br />http://CodeAndBeyond.org<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×