Solid Principles
-
Upload
martin-salias -
Category
Technology
-
view
1.388 -
download
1
Transcript of Solid Principles
![Page 1: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/1.jpg)
![Page 2: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/2.jpg)
Principios SOLIDMartín Salías
![Page 3: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/3.jpg)
Decadencia del software• Rigidez
• Fragilidad
• Inmovilidad
• Viscosidad
• Complejidad innecesaria
• Repetición innecesaria
• Opacidad
![Page 4: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/4.jpg)
Newsgroups: comp.objectFrom: [email protected] (Robert Martin)Date: Thu, 16 Mar 1995 15:12:00 GMTSubject: Re: The Ten Commandments of OO Programming---If I had to write commandments, these would be candidates. 1. Software entities (classes, modules, etc) should be open for extension, but closed for modification. (The open/closed principle -- Bertrand Meyer) 2. Derived classes must usable through the base class interface without the need for the user to know the difference. (The Liskov Substitution Principle) 3. Details should depend upon abstractions. Abstractions should not depend upon details. (Principle of Dependency Inversion) 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. 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. 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. 7. The dependency structure for released components must be a DAG. There can be no cycles. 8. Dependencies between released components must run in the direction of stability. The dependee must be more stable than the depender. 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. 10. Where possible, use proven patterns to solve design problems. 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.
![Page 5: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/5.jpg)
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
![Page 6: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/6.jpg)
Responsabilidad única
Abierto-Cerrado
Substitución de Liskov
Segregación de Interfaz
Inversión de Dependencia
![Page 7: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/7.jpg)
Una clase debe tener un único eje de cambio.
![Page 8: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/8.jpg)
Responsabilidad única
Una clase debe tener una única razón para ser cambiada.
Responsabilidad = Eje de cambios
(SI el cambio sucede)
Recibir el primer golpe
![Page 9: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/9.jpg)
Dos responsabilidades
AplicaciónGeométrica + Draw()
+ Area() : double
MyRectangle
AplicaciónGráfica
GUI
![Page 10: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/10.jpg)
Deslindando responsabilidades
AplicaciónGeométrica
+ Draw()
GraphRectangle
AplicaciónGráfica
GUI
+ Area() : double
GeoRectangle
AplicaciónGeométricaAplicación
GeométricaAplicación
GráficaAplicación
Geométrica
![Page 11: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/11.jpg)
Se debe poder extender el comportamiento sin modificarlo.
![Page 12: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/12.jpg)
Abierto-Cerrado
Las entidades de software (clases, módulos, funciones, etc) deben estar abiertas a
extensión, pero cerradas a modificación.
Acercarse a un ideal
Los cambios deben generar código nuevo,no modificar el código viejo.
![Page 13: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/13.jpg)
Cerrando a modificaciones
ServidorClienteEl cliente está abierto a modificaciones.
<<Interfaz>>IClienteCliente
Patrón Strategy: El cliente está abiertoy cerrado.
Servidor
![Page 14: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/14.jpg)
Cerrando a modificaciones
+ ReglaPolitica()- Servicio()
Política
- Servicio()
Implementación
Patrón Template Method:La clase base está cerradaa modificaciones.
La implementación delmétodo lo abre a cuantasextensiones se necesiten.
![Page 15: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/15.jpg)
Las clases derivadas deben poder sustituírse por sus bases.
![Page 16: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/16.jpg)
Substitución de LiskovLos subtipos deben ser substituibles
por sus tipos base.
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.
Es la base de poder del polimorfismo.
Cuidarse de GetType() y otros datos de tipo en runtime.
![Page 17: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/17.jpg)
Implicancias del LSP
• La validez depende del contexto
• No podemos validar un modelo aisladamente
• Diseñar basándose en comportamientos
• Presunciones razonables (¿cómo acotarlas?)
![Page 18: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/18.jpg)
Diseño por contrato• Preservar las invariantes
• Pre y pos-condiciones
• 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.
• Eiffel soporta nativamente DBC
• En .NET ó Java usamos Unit Tests
• Soporte incipiente en .NET 4
![Page 19: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/19.jpg)
Un ejemplo más complejo (1)
Lista
Listailimitada
Listalimitada
Listailimitada
Listalimitada
Librería
![Page 20: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/20.jpg)
Un ejemplo más complejo (2)
Lista
Listapersistente
Listapersistente
Librería
Listapersistente
![Page 21: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/21.jpg)
Un ejemplo más complejo (3)
Contenedor
Listapersistente
Librería
Listapersistente
Quitar(T)Existe(T)
Lista
Agregar(T)
ListaPersistenteAgregar(T)
![Page 22: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/22.jpg)
Produzca interfaces de grano fino específicas para un cliente.
![Page 23: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/23.jpg)
Segregación de Interfaz
Los clientes no deben ser forzados a depender de métodos que no usan.
• Apunta a evitar las interfaces “gordas”.
• No importa la cantidad de métodos, sino que todos sus clientes las utilicen.
• Inadvertidamente podemos acoplar clientes que usan ciertos métodos con otros clientes que no los usan.
![Page 24: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/24.jpg)
Una interfaz engorda
Puerta
+ Trabar()+ Destrabar()+ Abierta()
Timer<<interface>>Cliente Timer
+ TimeOut()
Puerta
Puerta temporizada
![Page 25: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/25.jpg)
Separación por delegación
Timer<<interface>>Cliente Timer
+ TimeOut()
Puerta
Puerta temporizada
Adapter Puerta Temporizada
+ TimeOut()
<<instancia>>
+ TimeOutPuerta()
![Page 26: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/26.jpg)
Separación por herencia múltiple
Timer<<interface>>Cliente Timer
+ TimeOut() Puerta
Puerta Temporizada
+ TimeOut()
![Page 27: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/27.jpg)
Dependa de abstracciones, no de concreciones.
![Page 28: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/28.jpg)
Inversión de dependenciaa) Los módulos de alto nivel no deben
depender de los módulos de bajo nivel. Ambos deben depender de abstracciones.
b) Las abstracciones no deben depender de detalles. Los detalles deben depender de las abstracciones.
Es el principio general detrás del concepto de Layers o Capas.
![Page 29: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/29.jpg)
Capas acopladasCapa
Política
CapaMecanismo
CapaUtilidad
![Page 30: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/30.jpg)
Política
Meca
nism
oU
tilidad
Capas desacopladas
CapaPolítica
CapaMecanismo
CapaUtilidad
<<interface>>Servicio de
políticas
<<interface>>Servicio de
mecanismos
![Page 31: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/31.jpg)
Recursos
Artículo del Tío Bob sobre diseño OOhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
![Page 32: Solid Principles](https://reader036.fdocuments.in/reader036/viewer/2022081514/55859b2fd8b42ad06d8b509e/html5/thumbnails/32.jpg)
Bibliografíaadicional
John Hunt David West
Matt Weisfeld Bertrand Meyer
Rebecca Wirfs-Brock
Scott Ambler