Solid Principles
Descargar como PPTX, PDF3 recomendaciones770 vistas
El documento presenta los principios SOLID de diseño orientado a objetos. Estos principios son: 1) Responsabilidad única, cada clase debe tener una única razón para cambiar, 2) Abierto-cerrado, las entidades deben estar abiertas a extensión pero cerradas a modificación, 3) Substitución de Liskov, los subtipos deben poder ser sustituibles por sus tipos base, 4) Segregación de interfaz, los clientes no deben depender de métodos que no usan, 5) Inversión de dependencia, las abstracciones no deb
Solid Principles
- 3. Decadencia del softwareRigidezFragilidadInmovilidadViscosidadComplejidad innecesariaRepetición innecesariaOpacidad
- 4. Newsgroups: comp.objectFrom: rmar...@rcmcon.com (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.
- 5. Single ResponsibilityOpen-ClosedLiskov SubstitutionInterface SegregationDependency Inversion
- 6. Responsabilidad únicaAbierto-CerradoSubstitución de LiskovSegregación de InterfazInversión de Dependencia
- 7. Unaclasedebetener un únicoeje de cambio.
- 8. Responsabilidad únicaUna clase debe tener una única razón para ser cambiada.Responsabilidad = Eje de cambios(SI el cambio sucede)Recibir el primer golpe
- 9. Dos responsabilidadesMyRectangleAplicaciónGeométricaAplicaciónGráfica+ Draw()+ Area() : doubleGUI
- 10. Deslindando responsabilidadesAplicaciónGráficaAplicaciónGráficaAplicaciónGeométricaAplicaciónGeométricaAplicaciónGeométricaAplicaciónGeométricaGeoRectangleGraphRectangle+ Area() : double+ Draw()GUI
- 11. Se debepoder extender el comportamiento sin modificarlo.
- 12. Abierto-CerradoLas entidades de software (clases, módulos, funciones, etc) deben estar abiertas a extensión, pero cerradas a modificación.Acercarse a un idealLos cambios deben generar código nuevo,no modificar el código viejo.
- 13. Cerrando a modificacionesEl cliente está abierto a modificaciones.ServidorCliente<<Interfaz>>IClienteClientePatrón Strategy: El cliente está abiertoy cerrado.Servidor
- 14. Cerrando a modificacionesPolíticaPatrón Template Method:La clase base está cerradaa modificaciones.+ ReglaPolitica()- Servicio()ImplementaciónLa implementación delmétodo lo abre a cuantasextensiones se necesiten.- Servicio()
- 16. Substitución de LiskovLos subtipos deben ser substituiblespor 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.
- 17. Implicancias del LSPLa validez depende del contextoNo podemos validar un modelo aisladamenteDiseñar basándose en comportamientosPresunciones razonables (¿cómo acotarlas?)
- 18. Diseño por contratoPreservar las invariantesPre y pos-condicionesLa 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 DBCEn .NET ó Java usamos Unit TestsSoporte incipiente en .NET 4
- 19. Un ejemplo más complejo (1)ListaLibreríaListailimitadaListailimitadaListalimitadaListalimitada
- 20. Un ejemplo más complejo (2)ListaLibreríaListapersistenteListapersistenteListapersistente
- 21. Un ejemplo más complejo (3)ContenedorLibreríaQuitar(T)Existe(T)ListapersistenteListapersistenteListaListaPersistenteAgregar(T)Agregar(T)
- 22. Produzca interfaces de granofinoespecíficaspara un cliente.
- 23. 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.
- 24. Una interfaz engordaTimer<<interface>>Cliente Timer+ TimeOut()Puerta+ Trabar()+ Destrabar()+ Abierta()PuertaPuerta temporizada
- 25. Separación por delegaciónTimer<<interface>>Cliente Timer+ TimeOut()PuertaPuerta temporizadaAdapter Puerta Temporizada+ TimeOut()+ TimeOutPuerta()<<instancia>>
- 26. Separación por herencia múltipleTimer<<interface>>Cliente TimerPuerta+ TimeOut()Puerta Temporizada+ TimeOut()
- 27. Dependa de abstracciones, no de concreciones.
- 28. Inversión de dependenciaLos módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de abstracciones.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.
- 30. Capas desacopladasPolíticaCapaPolítica<<interface>>Servicio depolíticasMecanismoCapaMecanismo<<interface>>Servicio demecanismosUtilidadCapaUtilidad
- 31. RecursosArtículo del Tío Bob sobrediseño OOhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- 32. BibliografíaadicionalMatt Weisfeld Bertrand MeyerRebecca Wirfs-Brock Scott AmblerJohn HuntDavid West
Notas del editor
- #3: SOLID principles5 principios rectores de OOD; la base de los patrones de diseño¿una novedad? -> NO
- #4: 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