Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

El la Orientación a Objetos un Problema o somos nosotros un problema para la OO

10,017 views

Published on

Evento "La Orientación a Objetos debe Moriri" #KillOOP Organizado por el Colegio Profesional de Ingenieros en Informática de Castilla y León.

Published in: Technology

El la Orientación a Objetos un Problema o somos nosotros un problema para la OO

  1. 1. ¿Es la OO un problema o somos nosotr os un problema para la OO? @jgarzas by Javier Garzás and
  2. 2. @jgarzas
  3. 3. ?
  4. 4. 1 2 3
  5. 5. ¿Sabemos OO? ¿Cuánta? ¿De dónde?
  6. 6. Mi tesis Doctoral (2004). Sobre OO y realizada 100% mientras sufría y trabajaba a “tiempo más que completo” desarrollando en OO
  7. 7. Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 16 EJEMPLO: BAD SMELLS 2) Métodos Largos 3) Declaraciones “switch” 4) Clases Grandes 5) Larga lista de Parámetros 6) Cambio Divergente 7) Shotgun Surgery 8) Feature Envy, 9) Data Clumps 10) Primitive Obsesión 11) Parallel Inheritance Hierarchies 12) Lazy Class 13) Speculative Generality 14) Message Chain 15) Middle Man 16) Inappropriate Intimacy 17) Incomplete Library Class 18) Data Class 19) Refused Bequest 20) Comentarios
  8. 8. Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 17 EJEMPLO: REFACTORIZACIÓN La refactorización (Refactoring) es una técnica para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo.
  9. 9. Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 18 EJEMPLO: HEURÍSTICAS • “Todos los datos deberían estar ocultos en su clase”. • “Minimizar el número de mensajes en el protocolo de una clase”. • “Eliminar las clases irrelevantes del diseño”. • “Eliminar clases que están fuera del sistema”. • “Una clase debería conocer lo que contiene pero nunca conocer quién la contiene”.
  10. 10. Inversión de la dependencia (inversión of control): evitar depender de clases concretas Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 19 EJEMPLO: PRINCIPIOS Clase A Abstracta B Clase B 2 Clase A Clase B 1
  11. 11. 147 Lista de referencias que en aquellos momentos leí “buscando la verdad”
  12. 12. Avión -Modelo -Color +Volar +Girar InterfazMotor + Acelerar + Frenar + CambiarAceite + CambiarCorrea Piloto -Nombre -NumLicenciaVuelo +Pilotar +PintaDatosPilotoEnHTML +Entrenar Motor R. Si entre una Interfaz y su implementación no hay una abstracción - VelocidadMax - Menos3000km: boolean + Acelerar + Frenar - AcelerarComoMenos3000km - AcelerarComoMasDe3000km por defecto P. IMPLICA PATRONES FACTORY AviónMilitar -Modelo -Color +Volar +Girar AviónComercial -Modelo -Color +Volar +Girar R. Si hay Súper Clases Concretas Azafata -Edad -Rango -DNI -NumeroPasajeros -NumPasjerosDiscapacitados -NumPasajerosConEscala -... +CogerBillete +ServirComida MecanicoMotores -NumeroLicencia -AñosExperiencia +RepararMotor R.Si una interfaz contiene servicios exclusivos a varios clientes R. Si hay Dependencia a Clases Concretas P. IMPLICA PATRON FACTORY P. PATRON FACTORY, No implicados por reglas P. PATRON STATE, No implicado por reglas R. Si hay elementos de la interfaz de usuario en entidades cuya responsabilidad es otra P. IMPLICA PATRONES OBSERVER P. IMPLICA PATRONES COMMAND
  13. 13. La curva de aprendizaje en OO (que no es solo programar en Java) es muy alta ...y no sé si ponemos/ tenemos todos los medios para rebajarla
  14. 14. ¿Conocemos suficientemente bien la OO para evitar mal código? 1
  15. 15. ¿Mal Código? ¿Buen Código?
  16. 16. ¿Por qué hacemos Diseño OO?
  17. 17. Si hay dependencias de clases concretas Si un Objeto tiene Diferente Comportamie nt o según su Estado SI una Jer arquía de Clases tiene Muchos Niveles Si algo se Uti liza muy Poco o No se Utiliza Si una Súper Clase Conoce a Alguna de sus Subclases SI una Clase Colabor a con Muchas Si Un Cambio en una Interfaz Impacta en Muchos Cl iente s Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 24 Sep 2004 27 RELACIONES ENTRE REGLAS Y PATRONES Abstract F. Adapter Class Adapter Object Bridge Builder Chain R. Command Composite Decorator Facade Fact. Method Flyweight Interpreter Iterator Mediator Memento Observer Prototype Proxy Singleton State Strategy Tem. Method. Visitor Implica uti liz ar X X X X Se Cumple en X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar X X Se Cumple en X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar X X Se Cumple en X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar Se Cumple en X X X X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar X X Se Cumple en X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar X Se Cumple en X X X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar Se Cumple en X X X X X X X X X X X X X X X X X X X X X X X Implica uti liz ar Se Cumple en Implica uti liz ar Se Cumple en X X X X X X X X X X X X X X X X X X X X X Si ent re una Interfaz y su Implementación no hay una Abst racción PATRONES Si una Superclase es Concr eta
  18. 18. implica utilizar Declarativo Conocimiento en Diseño de Micro Arquitecturas OO nombre propósito también conocido como motivación aplicabilidad participantes colaboración consecuencias diseño de ejemplo usos conocidos 0..n está compuesto de Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 24 Sep 2004 28 ONTOLOGÍA DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 0..n cumple 0..n 0..n 0..n 0..n 0..n implica utilizar Refactorización mecánica Regla recomendación Patrón estructura es introducido por 0..n { una, otra o las dos, pero siempre alguna} 0..n 1..n Operativo 0..n es introducido por
  19. 19. Una vez, cuando estaba en la OOPSLA (por aquellos tiempos el “glamour” no estaba en las conferencias ágiles, estaba en la OOPSLA…)
  20. 20. “Javier, nosotr os aplicando patr ones obtenemos peores métricas… ¿realmente los “buenos” diseños son de mayor calidad?”
  21. 21. ¿Qué es calidad?
  22. 22. ¿Esto es calidad?
  23. 23. Modelo factores/criterios/métricas (McCall) Prof. Javier Garzas – Grupo de Investigación Kybele – Calidad Software-­‐ Grado Ing. Software -­‐ Universidad Rey Juan Carlos
  24. 24. Modelo de Boehm Prof. Javier Garzas – Grupo de Investigación Kybele – Calidad Software-­‐ Grado Ing. Software -­‐ Universidad Rey Juan Carlos
  25. 25. Mantenibilidad
  26. 26. EJEMPLO D1 D2 D3 Observer Subject D1 D2 D3 Observer Subject D1 D2 D3 State StateA StateB a b c D1 Abstracta D2 D2 Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 24 Sep 2004
  27. 27. ¿Son los meta - meta – (¿mata?) diseños de mayor calidad?
  28. 28. Javier Garzás CARACTERIZACIÓN DEL CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS OO 24 Sep 2004 IMPACTO EN EL DISEÑO Numero de Patrones + + -­‐ -­‐ Cantidad Cambiabilidad Analizabilidad
  29. 29. ¿Sabemos qué “calidad” aporta un “buen” diseño OO? 2
  30. 30. ¿El problema es sólo de la OO?
  31. 31. Qué nos espera ahí fuera…
  32. 32. Por dónde empezamos…
  33. 33. ¿Medimos (y sabemos medir) malos diseños?
  34. 34. Los problemas OO no vienen solos
  35. 35. 3 El problema es que no nos vale sólo con saber buena OO necesitamos más (CV, Métricas, etc.)
  36. 36. ¿Es realmente el problema de la OO como paradigma?
  37. 37. (Yo creé en término OO y te puedo decir que no tenía C ++ en mente)
  38. 38. Gracias! @jgarzas
  39. 39. @jgarzas es.linkedin.com/in/jgarzas/ facebook.com/javiergarzas.blog www.javiergarzas.com
  40. 40. Realicé el mayor esfuerzo y propósito de referenciar fuentes y atribuir reconocimiento a todos los autores de los textos e imágenes que no fuesen míos, de reconocer los derechos de autor, etc. Pero si crees que algo se me ha pasado o que algo debe ser modificado, añadido o eliminado, por favor mándame un correo a jgarzas@gmail.com dfsfsdf

×