El documento describe los conceptos clave detrás del diseño orientado a objetos, incluyendo la metáfora de la célula, objetos, roles, responsabilidades y colaboraciones. Explica que los objetos encapsulan información y servicios y colaboran entre sí para resolver problemas mayores.

1. 1-Conceptos de DiseñoDr. Ricardo Quintero

2. La Metáfora de la CélulaAlan Kay utiliza la metáfora del Sistema Biológico para para explicar lo que deben ser los Objetos Software.Como las células, los Objetos Software no saben que es lo que sucede internamente en cada objeto, pero secomunican y trabajanen conjunto para realizar tareas complejas.En contraste, un Software Monolítico, es como un reloj mecánico que contiene innumerables engranes que funcionan sin inteligencia y en relación únicamente con los engranes adyacentes.“Cuando construyes un reloj de engranes, eventualmente alcanzas un nivel de complejidad que pone límites en si mismo” dice Alan Kay.

3. La Metáfora de la CélulaUn Objeto Software puede ser como una máquina que:Toma decisiones.Hace cosas.Conoce cosas.Colabora con muchos otros objetos potenciales.Viviendo en una máquina encerrada:Es un Todo en un nivel.Y una Parte en otro.El comportamiento del objeto está estrictamente limitado a aquello para lo que se le diseñó.Pero el comportamiento dinámico del Sistema Software surge a partir de las interacciones de muchos objetos (cada uno contribuyendo y jugando un rol responsable).

4. La Maquinaria de ObjetosUna Aplicación Software debe estar construida a partir de partes (los objetos).Estas partes interactúan enviando mensajes para solicitar alguna informacióno acción de otras partes.A lo largo de su tiempo de vida, cada objeto se mantiene responsable de responder a un conjunto fijo de solicitudes.Para atender estas peticiones, los objetos encapsulan respuestas y la información en la que se basan para estas respuestas.

5. El objeto encapsulando respuestas e información …Ejecuta ServiciosConoce informaciónUn ObjetoToma decisiones(para hacer lo correcto)Mantiene conexiones (a otros objetos)

6. Pregunta clave…¿Cómo inventamos estas Máquinas Software?

7. Respuesta clave …Construir una Aplicación Orientada a Objetos significa inventar la maquinaria apropiada en la cual representamos:Información del mundo real.Procesos.Interacciones.Relaciones.ErroresObjetos que no existen en la realidad (damos vida a cosas inanimadas).Descomponemos en objetos simples a objetos complejos (y difíciles de entender).

8. Respuesta clave …La medida del éxito es: que tan claramente inventamos la realidad del software que satisface los requisitos de la aplicación (y no que tanto se asemeja al mundo real).Al conectarse los objetos entre sí deben trabajar en concierto para construir máquinas muy complejas.Para manejar la complejidad, debemos repartirlos comportamientos del sistema en objetos que jueguen roles bien definidos.

9. Perspectivas complementarias para el diseño de aplicacionesEnfocados en el comportamiento, es posible diseñar una aplicación usando varias perspectivas complementarias:Una Aplicación = Un conjunto de objetos que interactúanUn Objeto = Una implementación de uno o más rolesUn Rol = Un conjunto de responsabilidades relacionadasUna Responsabilidad = Una obligación para realizar una tarea o conocer una informaciónUna Colaboración = Una interacción de objetos o roles (o ambos)Un Contrato = Un acuerdo enmarcando los términos de la colaboración.

10. RolesDentro de la maquinaría cada objeto tiene un propósito específico (el rol que juega dentro de un cierto contexto).Objetos que juegan el mismo rol pueden ser intercambiados.Así podemos definir Rol:“Un conjunto de responsabilidades que se pueden utilizar de forma intercambiable”Un rol es un slot en la maquinaría del software a ser llenado con un objeto apropiado conforme el programa se ejecuta.

11. Estereotipos de Roles de ObjetosPara enfocarse en las responsabilidades del objeto podemos utilizar Estereotipos de Roles.Los Estereotipos son caracterizaciones de los roles necesarios de las aplicaciones.A fin de construir objetos consistentes y fáciles de utilizar, es ventajoso estereotipar objetos ignorando los detalles específicos de los comportamientos y pensando en ellos a alto nivel.

12. Estereotipos útiles Los siguientes son estereotipos útiles:InformationHolder: conoce y provee información.Structurer: mantiene relaciones entre los objetos, así como también información de estas relaciones.ServiceProvider: realiza trabajo y, en general, ofrece servicios de cómputo.Coordinador: reacciona a eventos delegando tareas a otros.Controller: toma decisiones y dirige otras acciones.Interfacer: transforma información y solicitudes entre diferentes partes del sistema.Un objeto podría satisfacer más de un estereotipo, aunque podría tener asignada más de 1 responsabilidad (Un objeto ServiceProvider que maneja de forma privada la información necesaria para éste rol: 1 Rol con 2 Responsabilidades).

13. Roles, Responsabilidades y ColaboracionesUna Aplicación implementa un sistema de Responsabilidades.Las Responsabilidades son asignadas a los Roles.Los Roles colaboran para llevar a cabo las Responsabilidades.Una buena aplicación está estructurada para satisfacer efectivamente estas responsabilidades.Diseñar colaboraciones obliga a considerar objetos como participantes colaboradores y no como entidades aisladas.El Diseño es un proceso iterativo e incremental de visualizar objetos y sus responsabilidades e inventar colaboraciones flexibles dentro de pequeños vecindarios.

14. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …Ejecuta ServiciosConoce informaciónToma decisiones(para hacer lo correcto)Un ObjetoMantiene conexiones (a otros objetos)“Una aplicación es una comunidad de objetos trabajando juntos. Colaboran enviando mensajes y recibiendo respuestas. Contribuyen con su Conocimiento y Servicios”Mensaje solicitando ayudaUn Objeto

15. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …Un objeto puede ser más inteligente si hace algo con lo que conoce.Entre más inteligente el objeto, menos detalles debe conocer el cliente que utiliza sus servicios.Así los clientes se enfocan a resolver el problema, no en poner atención a detalles que sus colaboradores pueden resolver.Hacer objetos inteligentes tiene un efecto neto de elevar el IQ de toda la sociedad de objetos.

16. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …Parte del valor de un objeto está determinado por sus vecinos.Al concebir el diseño hay que considerar constantemente (respecto los vecinos): ¿Provee un servicio útil?¿Es fácil hablar con él?¿Es una “carga” porque continuamente solicita ayuda?¿Sus efectos son los deseados?Entre menos demandas hace un objeto, más fácil será de utilizar.Entre más tome cuidado, más útil será.

17. Contratos de ObjetosUn Contrato de un Objeto describe las condiciones bajo las cuales se garantiza su trabajo y los efectos que dejará una vez que el trabajo se complete.El Contrato de un Objeto responde a las preguntas:¿Con cuales objetos interactúa?¿Bajo que circunstancias es utilizado?¿Cuáles son los efectos a largo plazo que tendrá el objeto con su ambiente?Profundiza nuestro conocimiento de las responsabilidades del objeto y soporta nuestra confianza respecto a su diseño.Todo esto sin indicar como se cumplen con las responsabilidades.

18. Condiciones de Uso y Garantías de Efecto PosteriorLas Condiciones de Uso y las Garantías de Efecto Posterior definen los contratos.Las Condiciones de Uso responden a la pregunta:¿Bajo que condiciones puede el objeto garantizar sus servicios?Las Garantías de Efecto Posterior responden a la pregunta:¿Qué esperan los demás objetos de mí?Cuando un objeto se utiliza fuera de sus Condiciones de Uso no está obligado a satisfacer la petición.Las Condiciones de Uso en Diseño OO se reducen a las condiciones correctas bajo las cuales serán invocados los servicios aglutinados en las interfases de los objetos.

19. Objetos de DominioLos Objetos de Dominio ofrecen una base común sobre la cual desarrolladores y usuarios pueden converger y discutir la aplicación.Los Objetos de Dominio representan conceptos que son familiares a usuarios y expertos en un campo específico de interés.Ej.- En una aplicación bancaria: cuentas, depósitos, tasas de interés, etc.Para los desarrolladores estos objetos del dominio son solamente el punto inicial para construir un Modelo del Dominio útil para desarrollar las representaciones internas de éstos y conceptos adicionales que existirán en la maquinaria del software.

20. Modelo de DominioUn ProductoRelacionesProcesosUna OrdenUna Revisión del StockUna Historia CrediticiaUn ClienteInformaciónReglasUn DescuentoUna Regla de EmbarqueServicios

21. Modelo de DominioLos objetos en el Modelo de Dominio incorporan la lógica de la aplicación y sus interacciones.El M. de D. captura, al nivel más abstracto, la semántica de la aplicación y sus respuestas al ambiente.No se representan todos los conceptos del dominio solamente los que son necesarios para soportar la aplicación.

22. Objetos Específicos de la AplicaciónSimilarmente, necesitamos objetos para traducir las entradas del usuario (clics de mouse, tecleo) a comandos para objetos apropiados de la aplicación.Estos objetos transforman o filtran la información de usuario y después llaman a los objetos apropiados para la acción.Podrían también secuenciar al movimiento de pantallas, cambiar vistas o refrescar imágenes.Estos objetos específicos de aplicación proveen al Modelo de Dominio de comportamientos específicos del programa y se aglutinan con la aplicación.

23. Objetos Específicos de la AplicaciónAl iniciar una típica aplicación existe al menos 1 objeto de arranque que crea la población inicial de objetos y luego les pasa el control.Conforme el usuario navega a través de la aplicación, este grupo inicial de objetos responde a acciones de usuario ya sea satisfaciendo requisitos de la aplicación o creando y delegando trabajo a nuevos grupos de objetos diseñados para propósitos específicos.Conforme la ejecución continua, nuevos ciudadanos de esta comunidad de objetos nacen, viven y mueren (acorde a las necesidades –y diseño- de la aplicación).

24. Modelo de DominioUn ProductoRelacionesControlProcesosUn gestor de órdenesUna OrdenUn verificador de créditoUna Revisión del StockUna Historia CrediticiaCoordinaciónUn ClienteInformaciónUna ventanaInterfasesReglasUn DescuentoUna Regla de EmbarqueServicios

25. Vista del Usuario y Vista del DiseñadorAmbas vistas representan dos niveles diferentes de pensamiento sobre aplicaciones y objetos.La Vista del Usuario maneja una representación de conceptos del alto nivel (la información, servicios y reglas del dominio).La Vista del Diseñador inventa aspectos de coordinación y conectividad a otros sistemas y dispositivos, razona sobre la aplicación a un nivel diferente, más bajo: procesos de computadora, computaciones, traducciones, ejecución condicional, delegación, entradas, salidas.La clave para desarrollar una aplicación exitosa recae en nuestra habilidad para vincular estas dos vistas sin comprometer ninguna.

26. InterfasesEventualmente un objeto expresa sus responsabilidades sobre conocer (know) y hacer (do) a otros en métodos que contienen código.Una Interfase describe el vocabulario utilizado en el diálogo entre un objeto y sus clientes:“Bolea mis zapatos. Dame mis zapatos. Serán cinco pesos. Aquí está tu recibo”.La Interfasemanifiesta los servicios y explica como solicitarlos.Frecuentemente es importante conocer, además, las condiciones bajo las cuales un servicio puede ser invocado.Entre más se publique sobre el comportamiento de un objeto, más probable será que se utilice de acuerdo a su intención en el diseño.La interfase debe ser pública, la implementación privada u oculta.

27. ClasesEl término Clase se utiliza en matemáticas y en la vida real para describir “conjuntos de cosas”.Las clases son abstractas y conceptuales, las instancias concretas, objetos físicos.Esta noción aplica también a los objetos software, aunque las clases software poseen características que son específicas al mundo del software.

28. Dos rolesSi una clase software ofrece dos conjuntos distintos de servicios (usualmente a dos tipos de clientes), la clase se dice que juega dos roles:Primero, juega un rol que no tiene analogía en el mundo real: la clase actúa como una fábrica para crear las instancias requeridas del programa.Segundo, actúa como un objeto en sí mismo, con su propio conjunto de responsabilidades. Ofrece información y servicios a otros objetos a través de su propia interfase.

29. Dos roles: la clase actuando como FábricaUn clienteUn clienteUn clienteClaseClienteUn objetonew

30. Dos roles: la clase actuando como FábricaSolicitudes porInformación y Serviciosrelacionados con el ClienteClaseCliente como colaboradorUn objetoNecesita ayudaOfrece ayuda como cualquierotro objeto

31. Dos rolesCada instancia realiza sus tareas en dos contextos:Se comporta de acuerdo a reglas establecidas por la comunidad donde vive.Controla sus acciones de acuerdo a sus reglas y datos privados.Las reglas suelen estar representadas en condicionales en métodos. Los datos representan el estado del objeto. Incluyen, además, referencias a otros objetos las cuales permiten que pueda “ver” a otros y, subsecuentemente, interactuar con ellos.

32. Relaciones entre objetosExisten sólo dos tipos de relaciones entre objetos:ComposiciónHerenciaTienen analogía con el árbol familiar:La Composición es como un Matrimonio entre Objetos: es dinámica, sucede durante el tiempo de vida de los objetos y puede cambiar.La Herencia es como los Nacimientos en la familia: una vez que sucede es para siempre.Así como ambos existen en el árbol familiar, ambos también existen en cualquier sistema orientado a objetos.

33. ComposiciónEs posible extender las capacidades de un objeto a través de su composición con otros.Cuando carece de alguna característica que requiere para satisfacer sus responsabilidades, se delega simplemente a algún objeto con el cual tenga referencia (o conexión).Esto ofrece un escenario muy flexible: conforme el programa continua su ejecución los componentes se conectan entre sí, dinámicamente, de acuerdo a las condiciones de la aplicación.La Composición es uno de los mecanismos básicos para lograr la comunicación entre objetos; otros incluyen el paso de objetos ayuda en solicitudes o la creación de objetos.

34. HerenciaLa Herencia es otra forma de extender las capacidades de un objeto. A diferencia de la Composición, que es dinámica (en tiempo de ejecución), la Herencia es estática (en tiempo de compilación).En ocasiones las clases delegan su responsabilidad de crear objetos a sus subclases. Estas clases abstractas definen muchas de las características de las instancias, pero requieren de las subclases para completar algunos detalles y realizar la manufactura actual.

35. Organizaciones de ObjetosConforme se descompone la aplicación en piezas lógicas se pueden identificar objetos o roles y definir clases que implementen roles específicos.Se pueden diseñar elementos que posean cierta integridad lógica, pero que se puedan descomponer en piezas más pequeñas.Estos agrupamientos lógicos de colaboradores (confederaciones de objetos) suelen llamarse subsistemas o vecindades de objetos.Los subsistemas sirven a propósitos mayores de los que en lo individual pudieran realizar cualquier objeto.La sinergia de los esfuerzos corporativos entre los miembros del subsistema crea una nueva entidad conceptual, de más alto nivel.

36. Confederación de objetosUn solo objeto que representapúblicamente a todos los objetosEmpresa FinancieraACMELey ACMETu proveedor de servicioLicenciadoTu AgenteSu asistenteConceptualmente nohay diferencia entre las responsabilidadesde un Objeto y un Subsistema

37. ComponentesSon piezas de elementos de diseño cuya intención es utilizarlas en diferentes aplicaciones.Se pueden actualizar o reemplazar un componente sin reconfigurar el resto del sistema.Los aspectos internos del componente están ocultos, sus servicios están disponibles a través de una interfase bien definida.Para adaptarlos para su uso, un componente puede proveer interfases que permitan a sus clientes conectar componentes de ayuda o establecer propiedades para controlar aspectos de su operación.

38. PatronesLos pioneros de tecnología de objetos generaron muchas aplicaciones y estrategias de objetos para resolver problemas.Esta experiencia puede ser transmitida a las siguientes generaciones mediante Patrones.Un Patrón captura la experiencia de practicantes expertos presentando soluciones a problemas recurrentes comunes en un formato predecible y fácil de leer.

39. FrameworksUn Framework es un diseño general para resolver un problema de software.A diferencia de un patrón (una idea para resolver un problema familiar), un Framework ofrece una biblioteca de clases que los desarrolladores pueden particularizar o extender para satisfacer una situación particular.El éxito del Framework depende de que tan útil es a los desarrolladores y que tan fácil se pueden particularizar sus servicios a las necesidades.Problemas donde se han aplicado con éxito los Frameworks: GUI, Simulación, Ambientes de Programación (Eclipse), Aplicaciones Web.

40. Frameworks-VentajasVentajas al desarrollador:Eficiencia: menos diseño y codificación.Riqueza: el expertise del dominio se captura en el Framework.Consistencia: los desarrolladores se familiarizan con la filosofía impuesta por el Framework.Predecibilidad: el Framework lleva consigo varias iteraciones de desarrollo y pruebas.

41. Frameworks-DesventajasDesventajas al desarrollador:Complejidad: suelen tener una curva de aprendizaje pronunciada.Suelen requerir una estrategia específica para resolver un problema (si lo único que tienes es un martillo, todo parecerá clavo).Rendimiento: suele intercambiar flexibilidad y reusabilidad por rendimiento.

42. FrameworksLos Frameworks ofrecen soluciones genéricas pero carecen de comportamientos específicos que varían de aplicación en aplicación.Los comportamientos que se dejan incompletos son llamados hooks: implementaciones que se difieren a los programadores para aplicaciones específicas.Al codificar los hooks el programador debe aceptar una inversión en el control: nuestro código llama a otros objetos y se les pide que hagan el trabajo a favor nuestro.

43. ArquitecturaNo hay una única definición de Arquitectura de una aplicación.Una Arquitectura es una colección de comportamientos y un conjunto de descripciones sobre como se impactan unos a los otros.La Arquitectura, entonces, debe incluir aspectos estructurales y dinámicos.Los detalles internos de cómo un grupo de objetos realizan una tarea no deberían considerarse al diseñar una Arquitectura. En Arquitectura las interfases deben decirlo todo.

44. Estilos ArquitectónicosRepresentan estilos para organizar los objetos software.Hay 2 aspectos que se deben considerar cuando se piensa en un estilo arquitectónico:Estilos de Interacción de Componentes: muestran componentes o capas del sistema y describen como se les permite interactuar (capas, pipes & filters, blackboard).Estilos de Control: enfoques para distribuir responsabilidades para toma de decisiones y coodinación dentro y entre capas o componentes (desde altamente centralizado hasta distribuido).

45. Estilos ArquitectónicosCada combinación de Estilo Arquitéctonico soporta 1 o más características de calidad en un proyecto:UsabilidadDisponibilidadSeguridadRendimientoMantenibilidadFlexibilidadPortabilidad

46. Estilos ArquitectónicosPara soportar estos y otros atributos de calidad antes de realizar cualquier análisis, diseño, codificación podemos empezar seleccionando el Estilo Arquitectónico que los soportará.Seleccionar el Estilo Arquitectónico puede tener un alto impacto.

47. Estilo de Control CentralizadoHace una clara distinción entre datos y algoritmos.Cuando 1 Objeto Inteligente Central requiere computar datos, la pide a los Repositorios de Datos, los procesa y los regresa al mismo repositorio o a otro.La lógica de la aplicación está centralizada en los objetos inteligentes. El código puede ser difícil de leer porque está incrustado en una gran cantidad de lógica no afín, aunque sólo buscas en 1 solo lugar.

48. Estilo de Control CentralizadoLos objetos manejan información…La lógica inicia y termina aquí …

49. Estilo de Control Disperso: no centralizadoEn el otro extremo, se dispersa la lógica a través de toda la población de objetos, manteniendo cada objeto pequeño y construyendo la menor dependencia entre ellos. No hay una entidad central.Para determinar el funcionamiento, se debe trazar la secuencia de solicitudes a servicios a través de muchos objetos, por esto no es muy reutilizable.

50. Estilo de Control Disperso: no centralizadoLa lógica inicia aquí …La lógica finaliza aquí …

51. Estilo de Control DelegadoEstablece un compromiso (o balance) entre los 2 extremos mencionados.Cada objeto encapsula mucho de lo que se necesita para realizar las responsabilidades, pero en ocasiones requiere la ayuda de otros objetos capaces.Cada objeto tiene una pieza sustancial del pastel.Como cada objeto es muy capaz de realizar sus responsabilidades, por tanto es más usable.Las Funciones del Sistema se organizan en pools de responsabilidad que pueden utilizarse en forma relativamente aislada.

52. Estilo de Control DelegadoLos Objetos conocen y hacen algún sub-paso…Los coordinadores manejan cada paso…La lógica inicia aquí …La lógica termina aquí …

53. Estilo de CapasAgrupa responsabilidades en capas.Cada capa tiene un número bien definido de capas vecinas (1 o 2).Los objetos que viven en cada capa se comunican principalmente con objetos de la misma capa.Si los servicios que un objeto requiere no están en la capa los buscará en la capa adyacente.El Estilo de Capas contribuye a simplicidad, mantenibilidad y reusabilidad.

54. Estilo de Capas (aplicación Web)Browsers…PresentaciónControl y Coordinación de AplicaciónServidor Web…Servidor de Aplicaciones…Servicios e Información del DominioServidor de Base de Datos…Servicios de Base de Datos y Sistemas Legados

55. Cada capa tiene roles de objetos característicos…Interfases (ventanas y widgets)PresentaciónEventosResultadosCoordinadores y Controladores (de Aplicación)Servicios de AplicaciónContenedores de Información, Proveedores de Servicios, Estructuradores, Coordinadores y Controladores de DominioMensajesResultadosServicios del DominioMensajesResultadosServicios TécnicosIntefases

56. Comunicando objetos en/entre capasLa comunicación entre objetos tiende a seguir estas reglas:Los Objetos colaboran principalmente dentro de su propia capa.Cuando residen en capas diferentes, los objetos cliente suelen estar arriba de los objetos servidores. Los mensajes (peticiones) fluyen hacia “abajo”.La información (resultados) fluye hacia “arriba”.Cuando los mensajes fluyen hacia “arriba” los objetos cliente están en las capas bajas están débilmente acoplados a los servidores. Esto generalmente mediante un mecanismo de eventos.Sólo las capas más altas y bajas están expuestas al mundo “exterior”. Suelen manejar objetos específicos de plataforma (widgets en la capa alta,; interfases a redes, dispositivos y sistemas externos en las capas bajas).