Hispanopedia Wiki
Articulo de referencia

Diseño basado en la responsabilidad

El diseño basado en la responsabilidad es una técnica de diseño en la programación orientada a objetos que mejora la encapsulación mediante el modelo cliente-servidor . Se centr...

Hispanopedia WikiContenido en espanolLectura gratuita

El diseño basado en la responsabilidad es una técnica de diseño en la programación orientada a objetos que mejora la encapsulación mediante el modelo cliente-servidor . Se centra en el contrato , considerando las acciones de las que el objeto es responsable y la información que comparte. Fue propuesto por Rebecca Wirfs-Brock y Brian Wilkerson.

El diseño basado en responsabilidades 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 centra en utilizar los datos para determinar el flujo de control , no el diseño de clases.

En el modelo cliente-servidor al que se refieren, tanto el cliente como el servidor son clases o instancias de clases. En cualquier momento dado, el cliente o el servidor representan un objeto. Ambas partes se comprometen a un contrato e intercambian información al adherirse 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 orientado a la responsabilidad intenta evitar ocuparse de detalles, como la forma en que se ejecutan las solicitudes, especificando únicamente la intención de una solicitud determinada. El beneficio es una mayor encapsulación , ya que la especificación de la forma exacta en que se ejecuta una solicitud es privada para el servidor.

Para reforzar el aislamiento del servidor, Wirfs-Brock y Wilkerson proponen 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 . El lenguaje de programación Newspeak ofrece un control aún más preciso de la visibilidad de las clases .

Descripción general

El diseño orientado a la responsabilidad se centra en los objetos como abstracciones de comportamiento caracterizadas 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 posteriormente, según sea necesario. [ 2 ] Esto hace que el diseño siga una 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 centrarse desde el principio en los comportamientos para lograr las capacidades que cumplen con los requisitos establecidos y vincular posteriormente los detalles de implementación a dichos requisitos. Este enfoque ayuda especialmente a descentralizar el control y distribuir el comportamiento del sistema, lo que puede contribuir a gestionar la complejidad de sistemas grandes o distribuidos de alta funcionalidad . Asimismo, puede ayudar a diseñar y mantener mecanismos 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 bloques de construcción 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 entre sí. [ 5 ]
  • Candidatos: Los candidatos u objetos candidatos son conceptos clave en forma de objetos descritos en las 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 fichas utilizadas en el diseño inicial para registrar candidatos. [ 7 ] Estas tarjetas están divididas en un lado sin líneas y otro con líneas.
    • Contenido del lado rayado: En este lado se registran el nombre del candidato, sus responsabilidades y sus colaboradores. [ 7 ]
    • Contenido del lado sin líneas: En este lado se registra el nombre del candidato, su propósito en la solicitud, los roles estereotípicos y cualquier otra información relevante, como los nombres de los roles en los patrones en los que participa. [ 7 ]
  • Puntos críticos: Los puntos críticos son puntos en la aplicación donde ocurren variaciones. Se registran mediante tarjetas de puntos críticos. [ 8 ]
  • Tarjetas de puntos calientes: Las tarjetas de puntos calientes se utilizan para registrar variaciones con el nivel de detalle suficiente para poder distinguir las 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 interés
    • Descripción general de la variación
    • Al menos dos ejemplos específicos donde 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 funcionar en conjunto. Estos objetos desempeñan roles bien definidos y encapsulan respuestas e información predefinidas. [ 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 sujeto 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 ] Estas se clasifican además según lo que hacen.
      • Responsabilidades subordinadas: Estas incluyen los pasos principales en cada subresponsabilidad. [ 11 ]
      • Secuenciación de responsabilidades: Se refieren a la secuencia de ejecución de las responsabilidades subordinadas. [ 11 ]

Roles

El rol de un objeto se refiere a una visión externa del servicio general que ofrece. 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 la información. [ 13 ]
    • Proveedor de información: Una ligera variación del poseedor de información es el proveedor de información, que desempeña un papel más activo en la gestión y el mantenimiento de la información. Esta distinción puede utilizarse si un diseñador necesita ser más específico. [ 14 ]
  • Interfacer: Este rol transforma la información y las solicitudes entre distintas partes de una aplicación. [ 13 ] Se divide además en roles más específicos.
    • Interfaz externa: La interfaz externa 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 interna: También llamada interfaz entre sistemas. [ 14 ] Actúa como un puente entre vecindarios de objetos. [ 15 ]
    • Interfaz de usuario: La interfaz de usuario se comunica con los usuarios respondiendo a los eventos generados en la interfaz de usuario y luego pasándolos a los objetos más apropiados. [ 14 ] [ 15 ] [ 16 ]
  • Proveedor de servicios: Este rol realiza trabajo y ofrece servicios informáticos. [ 14 ]
  • Estructurador: Este rol mantiene las relaciones entre 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 centra en el 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. Estos 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 variaciones distintas. Sin embargo, estas no son definiciones precisas, ya que un estilo de control puede ser 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 concentra las responsabilidades de toma de decisiones importantes en solo unos pocos objetos o en un único objeto.

Tipos
  • Modelo de llamada y 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 desplaza hacia abajo. Se utiliza en un modelo secuencial.
  • Modelo de administrador  : El control de los objetos en la aplicación recae en un solo objeto. Generalmente, se implementa en modelos concurrentes. También puede implementarse en un modelo secuencial mediante una sentencia case .
Ventajas
  • La lógica de la aplicación se encuentra en un solo lugar.
Desventajas
  • La lógica de control puede volverse excesivamente compleja.
  • Los controladores pueden volverse dependientes del contenido de los poseedores de 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 usar

Cuando las decisiones que hay que tomar son pocas, sencillas y están relacionadas con una sola tarea.

Estilo de control delegado

El control delegado se sitúa entre el control centralizado y el descentralizado. Transfiere parte de la toma de decisiones y gran parte de la ejecución a los objetos que rodean un centro de control. Cada objeto vecino desempeña un papel importante. También se le conoce como modelo orientado a eventos, donde el control se delega al objeto que solicita procesar el evento.

Tipos[referencia]
  • Modelo de difusión  : Un evento se difunde a todos los objetos de la aplicación. El objeto que puede gestionar el evento adquiere el control.
  • Modelo basado en interrupciones  : Habrá un manejador de interrupciones para procesar la interrupción y pasarla a algún objeto para que la procese.
Ventajas
  • Es fácil de entender.
  • Aunque existe un coordinador externo, los objetos pueden hacerse más inteligentes para que sepan qué se supone que deben hacer y pueden reutilizarse en otras aplicaciones.
  • Los coordinadores que delegan tienden a conocer menos objetos que los controladores dominantes.
  • Los diálogos son de nivel superior.
  • Es fácil realizar cambios, ya que normalmente afectan a menos objetos.
  • Es más fácil dividir el trabajo de diseño entre los miembros del equipo.
Desventajas
  • Una excesiva distribución de la responsabilidad puede dar lugar a proyectos débiles y a colaboraciones débiles.
Cuándo usar

Cuando se desea 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 distribuye entre un grupo de objetos cuyas acciones están coordinadas. [ 19 ] La principal diferencia entre un estilo de control agrupado y uno delegado es que, en un estilo de control agrupado, los objetos que toman las decisiones se ubican dentro de un centro de control, mientras que en un estilo de control delegado se encuentran mayoritariamente fuera de él. [ 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 estableciendo la menor cantidad posible de dependencias entre ellos. [ 21 ]

Ventajas
  • Ninguno
Desventajas
  • Cuando quieres averiguar cómo funciona algo, debes rastrear la secuencia de solicitudes de servicios a través de muchos objetos.
  • No es muy reutilizable porque ningún objeto individual contribuye mucho
Cuándo usar

Nunca.

Estilo de control preferido

Tras los extensos resultados de los experimentos realizados, solo la alta dirección posee las habilidades necesarias para utilizar los programas de beneficios de estilo de control delegado y estilo de control centralizado. No se menciona ningún contexto sobre los empleados de nivel medio. [ 17 ]

Referencias

  1. ↑ 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 .
  2. ↑ Anthony JH Simons; Monique Snoeck; Kitty Hung (1998). "Design Patterns as Litmus Paper to Test the Strength of Object-Oriented Methods" . 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.
  3. ↑ Steven R. Haynes; Isaac G. Councill; Frank E. Ritter (2004). "Ingeniería de explicaciones basada en la responsabilidad para modelos cognitivos" .
  4. ↑ Wirfs-Brock, Rebecca; McKean, Alan (2003). Diseño de objetos: roles, responsabilidades y colaboraciones . Indianápolis, IN: Addison-Wesley. ISBN 978-0201379433.
  5. 1 2 3 4 5 Wirfs-Brock y McKean 2002 , págs. 3 
  6. ↑ Wirfs-Brock y McKean 2002 , pág. 58 
  7. 1 2 3 Wirfs-Brock y McKean 2002 , págs. 61 
  8. 1 2 Wirfs-Brock y McKean 2002 , págs. 72 
  9. 1 2 Wirfs-Brock y McKean 2002 , págs. 17 
  10. 1 2 Wirfs-Brock y McKean 2002 , págs. 126 
  11. 1 2 3 Wirfs-Brock y McKean 2002 , págs. 168 
  12. ↑ Wirfs-Brock y McKean 2002 , págs. 340 
  13. 1 2 3 4 5 Wirfs-Brock y McKean 2002 , págs. 4 
  14. 1 2 3 4 5 6 Wirfs-Brock y McKean 2002 , págs. 93 
  15. 1 2 3 Wirfs-Brock y McKean 2002 , págs. 165 
  16. ↑ Wirfs-Brock y McKean 2002 , pág. 164 
  17. 1 2 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 . 
  18. ↑ Wirfs-Brock y McKean 2002 , págs. 196 
  19. ↑ Wirfs-Brock y McKean 2002 , págs. 197 
  20. ↑ Wirfs-Brock y McKean 2002 , págs. 213 
  21. ↑ Wirfs-Brock y McKean 2002 , pág. 30 

Bibliografía

  • Diseño orientado a objetos: un enfoque basado en la responsabilidad . En Actas de la Conferencia 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.