4. Newsgroups: comp.object From: rmar...@rcmcon.com (Robert Martin) Date: Thu, 16 Mar 1995 15:12:00 GMT Subject: 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.
8. 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
12. 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.
13. Cerrando a modificaciones El cliente está abierto a modificaciones. Servidor Cliente <<Interfaz>> ICliente Cliente Patrón Strategy: El cliente está abierto y cerrado. Servidor
14. Cerrando a modificaciones Política Patrón Template Method: La clase base está cerradaa modificaciones. + ReglaPolitica() - Servicio() Implementación La implementación delmétodo lo abre a cuantasextensiones se necesiten. - Servicio()
16. Substitución de Liskov Los 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 LSP La validez depende del contexto No podemos validar un modelo aisladamente Diseñar basándose en comportamientos Presunciones razonables (¿cómo acotarlas?)
18. 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
19. Un ejemplo más complejo (1) Lista Librería Listailimitada Listailimitada Listalimitada Listalimitada
20. Un ejemplo más complejo (2) Lista Librería Listapersistente Listapersistente Listapersistente
21. Un ejemplo más complejo (3) Contenedor Librería Quitar(T) Existe(T) Listapersistente Listapersistente Lista ListaPersistente Agregar(T) Agregar(T)
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.
28. Inversión de dependencia Los 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.
SOLID principles5 principios rectores de OOD; la base de los patrones de diseño¿una novedad? -> 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
