Técnica de diseño en programación orientada a objetos
El diseño basado en responsabilidades es una técnica de diseño en la programación orientada a objetos que mejora la encapsulación mediante el uso del modelo cliente-servidor . Se centra en el contrato considerando las acciones de las que es responsable el objeto y la información que comparte. Fue propuesta por Rebecca Wirfs-Brock y Brian Wilkerson.
El diseño basado en la responsabilidad contrasta directamente con el diseño basado en datos, que promueve la definición del comportamiento de una clase junto con los datos que contiene. El diseño basado en datos no es lo mismo que la programación basada en datos , que se ocupa de utilizar datos para determinar el flujo de control , no el diseño de clases.
En el modelo cliente-servidor al que hacen referencia, tanto el cliente como el servidor son clases o instancias de clases. En cualquier momento particular, tanto el cliente como el servidor representan un objeto. Ambas partes se comprometen con un contrato e intercambian información adhiriéndose a él. El cliente solo puede realizar las solicitudes especificadas en el contrato y el servidor debe responder a estas solicitudes. [1] Por lo tanto, el diseño impulsado por la responsabilidad intenta evitar tratar con detalles, como la forma en que se llevan a cabo las solicitudes, al especificar solo la intención de una determinada solicitud. El beneficio es una mayor encapsulación , ya que la especificación de la forma exacta en que se lleva a cabo una solicitud es privada para el servidor.
Para encapsular aún más el servidor, Wirfs-Brock y Wilkerson piden características del lenguaje que limiten la influencia externa sobre el comportamiento de una clase. Exigen que la visibilidad de los miembros y las funciones sea muy precisa, como en el lenguaje de programación Eiffel . En el lenguaje de programación Newspeak se puede controlar aún más la visibilidad de las clases .
Descripción general
El diseño basado en responsabilidades se centra en los objetos como abstracciones de comportamiento que se caracterizan por sus responsabilidades. La técnica de modelado de tarjetas CRC se utiliza para generar estas abstracciones de comportamiento. El resto de la estructura del objeto, incluidos los atributos de datos, se asigna más tarde, cuando sea necesario. [2] Esto hace que el diseño siga la jerarquía de tipos para la herencia, lo que mejora la encapsulación y facilita la identificación de clases abstractas . También puede agrupar las clases en función de sus clientes, lo que se considera una capacidad única.
Un buen diseño orientado a objetos implica un enfoque temprano en los comportamientos para realizar las capacidades que satisfacen los requisitos establecidos y una vinculación tardía de los detalles de implementación a los requisitos. Este enfoque ayuda especialmente a descentralizar el control y distribuir el comportamiento del sistema, lo que puede ayudar a gestionar las complejidades de los sistemas grandes o distribuidos de alta funcionalidad. De manera similar, puede ayudar a diseñar y mantener instalaciones de explicación para modelos cognitivos , agentes inteligentes y otros sistemas basados en el conocimiento . [3]
Bloques de construcción
En su libro Object Design: Roles, Responsibilities and Collaborations , [4] los autores describen los siguientes componentes básicos que conforman el diseño impulsado por la responsabilidad.
- Aplicación: Una aplicación de software se define como un conjunto de objetos que interactúan. [5]
- Candidatos: Los candidatos u objetos candidatos son conceptos clave en forma de objetos descritos en tarjetas CRC. Sirven como invenciones iniciales en el proceso de diseño de objetos. [6]
- Colaboraciones: Una colaboración se define como una interacción de objetos o roles (o ambos). [5]
- Tarjetas CRC: CRC significa Candidatos, Responsabilidades, Colaboradores. Son tarjetas de índice que se usaban en los primeros diseños para registrar a los candidatos. [7] Estas tarjetas se dividen en un lado sin líneas y otro con líneas.
- Contenido del lado rayado: En este lado se consigna el nombre del candidato, sus responsabilidades y sus colaboradores. [7]
- Contenido del lado no rayado: En este lado se registra el nombre del candidato, su propósito en la aplicación, roles estereotipados y cualquier cosa que valga la pena como los nombres de los roles en los patrones en los que participa. [7]
- Puntos calientes: Los puntos calientes son puntos de la aplicación donde se producen variaciones. Se registran mediante tarjetas de puntos calientes. [8]
- Tarjetas de puntos calientes: las tarjetas de puntos calientes se utilizan para registrar variaciones con el detalle suficiente para poder discriminar diferencias importantes. Al igual que las tarjetas CRC, también se crean a partir de fichas . [8] Estas tarjetas constan de:
- Nombre del punto de acceso
- Descripción general de la variación
- Al menos dos ejemplos específicos en los que se produce la variación
Objetos
Los objetos se describen como cosas que tienen comportamientos similares a los de una máquina y que pueden conectarse entre sí para que funcionen en conjunto. Estos objetos desempeñan funciones bien definidas y encapsulan respuestas e información programadas. [5]
- Vecindarios de objetos: Otro término para subsistema. [9] Es una agrupación lógica de colaboradores. [9]
- Responsabilidades: Una responsabilidad es una obligación de realizar una tarea o conocer información. [5] Estas se clasifican además según su escenario de uso.
- Responsabilidades públicas: Las responsabilidades públicas son las responsabilidades que un objeto ofrece como servicios a otros y la información que proporciona a otros. [10]
- Responsabilidades privadas: Las responsabilidades privadas son las acciones que un objeto realiza en apoyo de las responsabilidades públicas. [10]
- Subresponsabilidades: A veces, una responsabilidad grande o complicada se divide en responsabilidades más pequeñas llamadas subresponsabilidades. [11] Se clasifican además en función de lo que hacen.
- Responsabilidades subordinadas: Incluyen los pasos principales de cada subresponsabilidad. [11]
- Secuenciación de responsabilidades: Se refiere a la secuenciación de la ejecución de las responsabilidades subordinadas. [11]
Roles
El rol de un objeto se refiere a una vista exterior de qué servicio general ofrece el objeto. Es un conjunto de responsabilidades relacionadas. [5] Puede implementarse como una clase o una interfaz. Sin embargo, la interfaz es la implementación preferida, ya que aumenta la flexibilidad al ocultar la clase concreta que, en última instancia, realiza el trabajo. [12]
Estereotipos de roles: Los estereotipos de roles son roles simplificados que vienen con responsabilidades predefinidas. [13] Hay varias categorías.
- Controlador: El objeto que implementa este rol toma decisiones y dirige de cerca la acción de otros objetos. [13]
- Coordinador: Este rol reacciona a los eventos delegando tareas a otros. [13]
- Titular de la información: El titular de la información conoce y proporciona información. [13]
- Proveedor de información: una ligera variación del poseedor de información es el proveedor de información, que asume un papel más activo en la gestión y el mantenimiento de la información. Esta distinción se puede utilizar si un diseñador necesita ser más específico. [14]
- Interfazdor: este rol transforma información y solicitudes entre distintas partes de una aplicación. [13] Se divide a su vez en roles más específicos.
- Interfaz externo: el interfaz externo se comunica con otras aplicaciones en lugar de con la suya propia. [14] Se utiliza principalmente para encapsular API no orientadas a objetos y no colabora mucho. [15]
- Interfaz interno: también llamado interfaz entre sistemas. [14] Actúa como un puente entre los vecindarios de los objetos. [15]
- Interfaz de usuario: el interfaz de usuario se comunica con los usuarios respondiendo a los eventos generados en la interfaz de usuario y luego pasándolos a objetos más apropiados. [14] [15] [16]
- Proveedor de servicios: este rol realiza trabajos y ofrece servicios informáticos. [14]
- Estructurador: este rol mantiene las relaciones entre los objetos y la información sobre esas relaciones. [14]
Estilo de control
Una parte importante del proceso de diseño basado en responsabilidades es la distribución de las responsabilidades de control, lo que da como resultado el desarrollo de un estilo de control. Un estilo de control se ocupa del flujo de control entre subsistemas.
- Concepto de Control: Las responsabilidades y colaboraciones entre las clases. [17]
- Centros de control: Un aspecto importante del desarrollo de un estilo de control es la invención de los llamados centros de control, que son lugares donde residen los objetos encargados de controlar y coordinar. [18]
- Variaciones del estilo de control: un estilo de control se presenta en tres variantes distintas. Sin embargo, no se trata de definiciones precisas, ya que se puede decir que un estilo de control es más centralizado o delegado que otro.
Estilo de control centralizado
Este estilo de control impone un paradigma procedimental a la estructura de la aplicación y coloca las responsabilidades de toma de decisiones importantes en sólo unos pocos objetos o en un único objeto.
- Tipos
- Modelo de llamada-retorno: El control de los objetos en la aplicación se realiza de forma jerárquica. El control comienza en la raíz y se va desplazando hacia abajo. Se utiliza en un modelo secuencial.
- Modelo de administrador: el control de los objetos de la aplicación se realiza con un solo objeto. Generalmente, se implementa en modelos concurrentes. También se puede implementar en modelos secuenciales mediante la declaración case .
- Ventajas
- La lógica de la aplicación está en un solo lugar.
- Desventajas
- La lógica de control puede volverse demasiado compleja
- Los responsables del tratamiento pueden llegar a depender del contenido de los titulares de la información
- Los objetos pueden acoplarse indirectamente a través de las acciones de su controlador.
- El único trabajo interesante se realiza en el controlador.
- Cuándo utilizar
Cuando las decisiones a tomar son pocas, sencillas y relacionadas con una única tarea.
Estilo de control delegado
Un estilo de control delegado se encuentra entre un estilo de control centralizado y uno disperso. Pasa parte de la toma de decisiones y gran parte de la acción a objetos que rodean un centro de control. Cada objeto vecino tiene un papel importante que desempeñar. También se puede denominar modelo impulsado por eventos, en el que el control se delega al objeto que le solicita que procese el evento.
- Tipos[referencia]
- Modelo de difusión: un evento se difunde a todos los objetos de la aplicación. El objeto que puede controlar el evento puede adquirir el control.
- Modelo impulsado por interrupciones: habrá un controlador de interrupciones para procesar la interrupción y pasarla a algún objeto para procesarla.
- Ventajas
- Es fácil de entender.
- Aunque existe un coordinador externo, los objetos pueden hacerse más inteligentes para saber qué se supone que deben hacer y pueden reutilizarse en otras aplicaciones.
- Los coordinadores delegantes tienden a saber sobre menos objetos que los controladores dominantes.
- Los diálogos son de nivel superior.
- Es fácil cambiarlo ya que los cambios generalmente afectan a menos objetos.
- Es más fácil dividir el trabajo de diseño entre los miembros del equipo.
- Desventajas
- Una distribución excesiva de responsabilidades puede dar lugar a objetos débiles y colaboraciones débiles.
- Cuándo utilizar
Cuando se quiere delegar trabajo a objetos más especializados.
Estilo de control agrupado
Este estilo de control es una variación del estilo de control centralizado en el que el control se reparte entre un grupo de objetos cuyas acciones están coordinadas. [19] La principal diferencia entre un estilo de control agrupado y delegado es que en un estilo de control agrupado, los objetos de toma de decisiones se encuentran dentro de un centro de control, mientras que en un estilo de control delegado se encuentran principalmente fuera. [20]
Estilo de control disperso
Un estilo de control disperso no contiene ningún centro de control. La lógica se distribuye entre toda la población de objetos, manteniendo cada objeto pequeño y creando la menor cantidad posible de dependencias entre ellos. [21]
- Ventajas
- Desventajas
- Cuando desea saber cómo funciona algo, debe rastrear la secuencia de solicitudes de servicios en muchos objetos.
- No es muy reutilizable porque ningún objeto individual aporta mucho.
- Cuándo utilizar
Nunca.
Estilo de control preferido
Tras los resultados de los experimentos realizados, sólo la alta dirección tiene las habilidades necesarias para hacer uso de los beneficios del estilo de control delegado y del estilo de control centralizado para los programadores. No se menciona ningún contexto sobre los empleados de nivel medio. [17]
Referencias
- ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). "Diseño orientado a objetos: un enfoque basado en la responsabilidad". ACM SIGPLAN Notices . 24 (10): 74. doi : 10.1145/74878.74885 .
- ^ Anthony JH Simons; Monique Snoeck; Kitty Hung (1998). "Patrones de diseño como papel tornasol para probar la solidez de los métodos orientados a objetos". Oois'98 . pp. 129–147. CiteSeerX 10.1.1.130.8713 . doi :10.1007/978-1-4471-0895-5_10. ISBN 978-1-85233-046-0.
- ^ Steven R. Haynes; Isaac G. Councill; Frank E. Ritter (2004). "Ingeniería explicativa basada en la responsabilidad para modelos cognitivos".
- ^ Wirfs-Brock, Rebecca; McKean, Alan (2003). Diseño de objetos: roles, responsabilidades y colaboraciones . Indianápolis, IN: Addison-Wesley. ISBN 978-0201379433.
- ^ abcde Wirfs-Brock y McKean 2002, págs. 3
- ^ Wirfs-Brock y McKean 2002, págs. 58
- ^ abc Wirfs-Brock y McKean 2002, págs. 61
- ^ Véase Wirfs-Brock y McKean 2002, págs. 72
- ^ Véase Wirfs-Brock y McKean 2002, págs. 17
- ^ Véase Wirfs-Brock y McKean 2002, págs. 126
- ^ abc Wirfs-Brock y McKean 2002, págs. 168
- ^ Wirfs-Brock y McKean 2002, págs. 340
- ^ abcde Wirfs-Brock y McKean 2002, págs. 4
- ^ abcdef Wirfs-Brock y McKean 2002, págs. 93
- ^ abc Wirfs-Brock y McKean 2002, págs. 165
- ^ Wirfs-Brock y McKean 2002, págs. 164
- ^ ab Eric, Arisholm; Dag IK, Sjoberg (2004). "Evaluación del efecto de un estilo de control delegado versus centralizado en la mantenibilidad del software orientado a objetos". IEEE Transactions on Software Engineering . 30 (8): 521–534. doi :10.1109/TSE.2004.43. S2CID 6396127.
- ^ Wirfs-Brock y McKean 2002, págs. 196
- ^ Wirfs-Brock y McKean 2002, págs. 197
- ^ Wirfs-Brock y McKean 2002, págs. 213
- ^ Wirfs-Brock y McKean 2002, págs. 30
Bibliografía
- Diseño orientado a objetos: un enfoque basado en la responsabilidad. En Actas de congresos sobre sistemas, lenguajes y aplicaciones de programación orientada a objetos (Nueva Orleans, Luisiana, Estados Unidos, 2-6 de octubre de 1989). OOPSLA '89. ACM Press, Nueva York, NY, 71-75.
- Wirfs-Brock, Rebecca; McKean, Alan (noviembre de 2002). Diseño de objetos: roles, responsabilidades y colaboraciones . Addison Wesley . ISBN 978-0-201-37943-3.
