¿Por qué?
|
|
|
Diseño modular no asegura un código calidad | ||
---|---|---|
Una única clase asume la responsabilidad de toda la jerarquía |
|
|
Existe una clase por cada tipo de elemento que asumen sus correspondientes responsabilidades |
|
|
Existe una jerarquía de clases por cada tipo de elemento que asumen sus correspondientes responsabilidades |
|
¿Qué?
OOP para mí significa solo mensajería, retención local, protección y ocultación del estado del proceso, y vinculación tardía extrema de todas las cosas. Se puede hacer en Smalltalk y en LISP. Posiblemente hay otros sistemas en los que esto es posible, pero no los conozco.
— Alan Kay
Meaning of “Object-Oriented Programming” |
Mi conjetura es que la orientación a objetos será en los 80 lo que la programación estructurada en los 70. Todo el mundo estará a favor suyo. Cada productor prometerá que sus productos lo soportan. Cada director pagará con la boca pequeña el servirlo. Cada programador lo practicará. Y nadie sabrá exactamente lo que es!
— Rentsch
Object-Oriented Programming. SIGPLAN Notices vol. 17(12). 1982 |
X es bueno. Orientado a Objetos es bueno. Ergo, X es Orientado a Objetos
— Stroupstrup
The C++ Programming Language. 1988 |
Programación Orientada a Objetos = Clases + Herencia |
Herencia | Polimorfismo | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
||||||||||||
|
|
Teoría de Lenguajes
|
|
Enlace estático | Enlace dinámico |
---|---|
enlace que se puede resolver en tiempo de compilación, el valor de la característica se puede determinar mirando el código |
enlace que solo se puede resolver en tiempo de ejecución, el valor de la característica se puede determinar en un instante de la ejecución del código |
|
|
Datos polimórficos
|
|
|
Sin polimorfismo | Con polimorfismo |
---|---|
Enlace estático, para toda expresión puede deducirse el tipo del valor del resultado de su evaluación en tiempo de compilación |
Enlace dinámico, existen expresiones para las que no puede deducirse el tipo del valor del resultado de su evaluación en tiempo de compilación |
Incluso con sobrecarga pero restringida para varios métodos con el mismo nombre y con diferentes parámetros, en número y/o tipos correspondientes, para evitar la ambigüedad con el tipo del valor de retorno |
Con cualquier expresión que devuelva la dirección a un objeto declarada a una clase base, dado que el tipo del objeto referenciado puede ser de la clase base, si no es abstracta, o de cualquiera de sus descendientes, por la "relajación del sistema de tipos" del polimorfismo |
Operaciones polimórficas
|
|
Sin polimorfismo | Con polimorfismo |
---|---|
Enlace estático, un mensaje lanzado a un objeto ejecutará el método con el mismo nombre y parámetros, en número y tipos correspondientes, de la clase del objeto |
Enlace dinámico, un mensaje lanzado a un objeto polimórfico ejecutará un método con el mismo nombre y parámetros, en número y tipos correspondientes, de alguna de las clases de la jerarquía a partir de la clase base de la referencia |
Incluso con sobrecarga pero restringida para varios métodos con los mismos parámetros, en número y tipos correspondientes, para evitar la ambigüedad con el tipo del valor de retorno |
Con cualquier expresión que devuelva una referencia/puntero a una clase base, dado que el tipo del objeto referenciado puede ser de la clase base, si no es abstracta, o de cualquiera de sus descendientes, por la "relajación del sistema de tipos" del polimorfismo |
¿Para qué?
|
|
] |
Fluido | Flexible | Resuable | Robusto |
---|---|---|---|
Presencia de multitud de clases pequeñas con métodos pequeños con pequeños acoplamientos acíclicos que puedo recorrer de arriba abajo (top/down o bottom/up), jerarquía de composición y/o clasificación de clases pequeñas, sin ciclos! |
Reparto de responsabilidades equilibrado y centralizado en clases que requiere modificarse únicamente si cambian los requisitos correspondientes, jerarquías de clases con alta cohesión, sin ciclos! |
Presencia de multitud de clases pequeñas, cohesivas y poco acopladas a tecnologías, algoritmos, …! |
Presencia de red de seguridad de pruebas unitarias por posibilidad de realizar pruebas sobre las clases anteriores … jerarquía equilibrada de clases pequeñas con alta cohesión y bajo acoplamiento! |
Principio Abierto/Cerrado
|
Motivación | Solución |
---|---|
|
|
Violaciones | Contraindicaciones: |
---|---|
|
|
¿Cómo?
Clasificación
Clases Abstractas e Interfaces
- Clases Abstractas | - Interfaces |
---|---|
|
|
|
|
|
|
Aportan abstracción/encapsulación, modularidad, bajo acoplamiento, cohesión!!! |
Código Sucio por Herencia Rechazada
Justificación | Solución |
---|---|
|
|
Ley Flexible y Estricta de Demeter
Sinónimos | Synonyms | Libro | Autor |
---|---|---|---|
No hablescon extraños |
Do not talk to strangers |
Lieberherr |
|
Cadena de Mensajes |
Chain of Message |
Smell Code (Refactoring) |
Martin Fowler |
Ley estricta de Demeter | Ley flexible de Demeter |
---|---|
|
|
|
|
Reusabilidad
Patrón Método Plantilla
Sinónimos | Synonyms | Libro | Autor |
---|---|---|---|
Método Plantilla |
Template Method |
Patrones de Diseño |
Gamma et al |
Justificación | Solución |
---|---|
|
|
|
|
|
|
Herencia vs Composición
Composición | Herencia |
---|---|
Reusabilidad por ensamblado |
Reusabilidad por extensión |
|
|
Reusabilidad con desarrollo explícito en el código, declarando los atributos que son parte del todo y enviando mensajes para su gestión |
Reusabilidad implícita en el lenguaje, declarando la herencia se transmiten automáticamente todos los atributos y métodos, públicos, protegidos, privados y de paquete, con unos accesos u otros dependiendo del punto de vista (clase cliente o clase descendiente) |
Más objetos para la reusabilidad, se tiene un objeto para el todo y otro para la parte y, por tanto, menos eficiente por la re-emisión de mensajes del objeto "todo" al objeto "parte" |
Menos objetos para la reusabilidad, se tiene un objeto de la clase descendiente y, por tanto, más eficiente por la emisión directa de mensajes al objeto "descendiente" |
Relación dinámica entre objetos, por tanto es más flexible porque un todo puede colaborar con distintas partes en el tiempo creando nuevos objetos |
Relación estática entre clases, por tanto es menos flexible porque un objeto de la clase descendiente es y será un objeto de la clase descendiente sin poder modificar su clase base en tiempo de ejecución |
Caja negra, desde la clase todo se tiene acceso a miembros públicos de la parte, sin posibilidad de modificar el código reusado |
Caja blanca, desde la calse descendiente se tiene acceso a miembros públicos y protegidos y de paquete, con posiblidad de modificar el código reusado mediante la redefinción (@Override) |
Fácil de mantener porque es imposible romper el principio de encapsulación |
Difícil de mantener porque es fácil romper el principio de encapsulación |
Herencia vs Parametrización
|
|
Lista de cerdos | Lista de deseos | Lista genérica |
---|---|---|
|
|
|
Flexiblidad
Principio de Sustitución de Liskov
|
Lo que se quiere aquí es algo como la siguiente propiedad de sustitución: si para cada objeto oT de un tipo T, hay un objeto oS de tipo S tal que para todo progama P definido en términos de T, el comportamiento de P no cambia cuando oT es sustituido por oS, entonces S es un subtipo de T
— Barbara Liskov
A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems (TOPLAS). Volume 16. Issue 6 (November 1994). pp. 1811. 1841 |
Justificación | Violaciones |
---|---|
|
|
Se cumple cuando se redefine un método en una derivada reemplazando su precondición por una más débil y su postcondicion por una más fuerte
— Barbara Liskov
Principio de Sustitución |
|
Aplicaciones | ||
---|---|---|
|
Herencia vs Delegación
Motivación | Solución |
---|---|
|
|
Relación de Herencia | Relación de Composición para Delegación |
---|---|
Relación de Herencia | Relación de Composición para Delegación |
---|---|
Aplicaciones | ||
---|---|---|
|
Código Sucio por Jerarquías Paralelas de Herencia
Justificación | Solución | |
---|---|---|
|
|
|
Técnica de Doble Despacho
|
|
1ª solución: preguntando por el tipo del objeto polimórfico | |
---|---|
|
|
|
2ª solución: aplicando la técnica de doble despacho | |
---|---|
|
|
|
3ª solución: principio abierto/cerrado | |
---|---|
|
|
|
Aplicaciones | ||
---|---|---|
|
Inversión de Control
Sinónimos | Synonyms |
---|---|
Principio Hollywood: “No me llames, ya te llamaremos” |
Hollywood Principle: "Don’t call me, we’ll call you" |
|
Una característica importante de un framework es que los métodos definidos por el usuario para adaptar el framework, a menudo se llaman desde dentro del propio framework, en lugar desde el código de la aplicación del usuario. El framework a menudo desempeña el papel del programa principal en la coordinación y secuenciación de actividad de la aplicación. Esta inversión de control da al framework el poder para servir como esqueletos extensibles. Los métodos suministrados por el usuario se adaptan a los algoritmos genéricos definidos en el framework para una aplicación particular
— Johonson & Foote
1988 |
“algunas personas confunden el principio general de Inversión de Control con los estilos específicos de Inversión de Control, como la Inyección de Dependencias, que estos contenedores utilizan”
— Fowler
|
|
Inyección de Dependencias
Sinónimos | Synonyms | Libro | Autor |
---|---|---|---|
Inyección de Dependencias |
Pluggin |
||
Patrón de Diseño Estrategia |
Strategy Pattern Design |
Patrones de Diseño |
Gamma et al |
Justificación | Solución |
---|---|
|
|
Sin Inyección de Dependencias | Con Inyección de Dependencias por constructor | Con Inyección de Dependencias por método |
---|---|---|
|
|
|
Ocultación de Información
Principio Separación de Interfaces
Los clientes no deberían forzarse a depender de interfaces que no usan
— Robert Martin
Principio de Separación de Interfaces |
|
Motivación | Solución |
---|---|
|
|
|
|
Diseño | Implementación |
---|---|
Violando Principio de Ocultación de la Información |
|
|
|
Incorporando Complejidad Arbitraria |
|
|
|
Solución con Interfaces, como mecanismo de Ocultación de la Información |
|
|
|
Principio de Separación de Interfaces | Compromiso |
---|---|
|
|
Principio de Inversión de Dependencias
Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones
— Robert Martin
Principio de Inversión de Dependencias |
|
Motivación | Justificación | Solución | Compromisos |
---|---|---|---|
|
|
|
|
Sin Principio de Inversión de Dependencias | Con Principio de Inversión de Dependencias |
---|---|
|
|
Sin Principio de Inversión de Dependencias | Con Principio de Inversión de Dependencias |
---|---|
|
|
Sintesis
Bibliografía
Obra, Autor y Edición | Portada | Obra, Autor y Edición | Portada |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ponente
|
|
|