De Wikipedia, la enciclopedia libre
  (Redirigido desde el diseño basado en datos )
Saltar a navegación Saltar a búsqueda

El diseño impulsado por la responsabilidad 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 el objeto. Fue propuesto 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 del uso de datos para determinar el flujo de control , no del 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 un momento determinado, el cliente o el servidor representan un objeto. Ambas partes se comprometen a 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, especificando en cambio 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 realiza una solicitud es privada para el servidor.

Para promover la encapsulación del servidor, Wirfs-Brock y Wilkerson piden características del lenguaje que limiten la influencia externa al comportamiento de una clase. Exigen que la visibilidad de los miembros y las funciones sea fina, como en el lenguaje de programación de Eiffel . El lenguaje de programación Newspeak ofrece un control aún más preciso de la visibilidad de las clases uniformes .

Resumen [ editar ]

El diseño impulsado por la responsabilidad 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 asignan más tarde, según 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 habilidad única.

Un buen diseño orientado a objetos implica un enfoque temprano en los comportamientos para realizar las capacidades que cumplen con 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 facilidades de explicación para modelos cognitivos , agentes inteligentes y otros sistemas basados ​​en el conocimiento. [3]

Bloques de construcción [ editar ]

En su libro Diseño de objetos: roles, responsabilidades y colaboraciones , [4] los autores describen los siguientes bloques de construcción que componen el diseño impulsado por la responsabilidad.

  • Aplicación: una aplicación de software se conoce como un conjunto de objetos que interactúan. [5]
  • Candidatos: Los candidatos o los 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 que se utilizan en los primeros diseños para registrar candidatos. [7] Estas tarjetas se dividen en un lado sin forro y otro con líneas.
    • Contenido del lado rayado: En este lado se registra 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, los 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 en la aplicación donde ocurren variaciones. Se graban mediante tarjetas Hot Spot. [8]
  • Tarjetas de puntos calientes: las tarjetas de puntos calientes se utilizan para registrar variaciones con el detalle suficiente para que pueda 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 donde ocurre la variación

Objetos [ editar ]

Los objetos se describen como cosas que tienen comportamientos similares a las de una máquina que se pueden conectar para trabajar en conjunto. Estos objetos desempeñan funciones bien definidas y encapsulan respuestas e información programadas. [5]

  • Barrios 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] Estos 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 realiza un objeto en apoyo de las responsabilidades públicas. [10]
    • Subresponsabilidades: a veces, una responsabilidad grande o complicada se divide en otras más pequeñas llamadas subresponsabilidades. [11] Se clasifican además en función de lo que hacen.
      • Responsabilidades subordinadas: Incluyen los pasos principales en cada subresponsabilidad. [11]
      • Responsabilidades de secuenciación: Se refieren a la secuenciación de la ejecución de responsabilidades subordinadas. [11]

Roles [ editar ]

El rol del objeto se refiere a una vista exterior del servicio general que ofrece el objeto. Es un conjunto de responsabilidades relacionadas. [5] Se puede implementar como una clase o una interfaz. La interfaz, sin embargo, es la implementación preferida ya que aumenta la flexibilidad al ocultar la clase concreta que finalmente hace 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 pequeña variación de un 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]
  • Interfaz: esta función transforma la información y las solicitudes entre distintas partes de una aplicación. [13] Además, se divide en funciones más específicas.
    • Interfaz externa: la interfaz externa se comunica con otras aplicaciones en lugar de con la 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 objetos más apropiados. [14] [15] [16]
  • Proveedor de servicios: esta función realiza trabajos y ofrece servicios informáticos. [14]
  • Estructurador: este rol mantiene relaciones entre objetos e información sobre esas relaciones. [14]

Estilo de control [ editar ]

Una parte importante en el proceso de diseño impulsado por la responsabilidad es la distribución de las responsabilidades de control que da como resultado el desarrollo de un estilo de control. Un estilo de control se preocupa por 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 se puede decir que un estilo de control está más centralizado o delegado que otro.

Estilo de control centralizado [ editar ]

Este estilo de control impone un paradigma de procedimiento en la estructura de la aplicación y coloca las responsabilidades de toma de decisiones importantes en solo unos pocos objetos o un solo objeto.

Tipos
  • Modelo de devolución de llamada: El control de los objetos de la aplicación es jerárquico. El control comienza en la raíz y se mueve hacia abajo. Se utiliza en un modelo secuencial.
  • Modelo de administrador: el control de los objetos en la aplicación se realiza con un solo objeto. Generalmente, se implementa en modelos concurrentes. También se puede implementar en un modelo secuencial utilizando una declaración de caso .
Ventajas
  • La lógica de la aplicación está en un solo lugar.
Desventajas
  • La lógica de control puede volverse demasiado compleja
  • Los controladores pueden volverse dependientes 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 usar

Cuando las decisiones a tomar son pocas, sencillas y relacionadas con una sola tarea.

Estilo de control delegado [ editar ]

Un estilo de control delegado se encuentra entre un estilo de control centralizado y disperso. Pasa parte de la toma de decisiones y gran parte de la acción a los objetos que rodean un centro de control. Cada objeto vecino tiene un papel importante que desempeñar. También se puede llamar como modelo impulsado por eventos, donde el control se delega al objeto que solicita que procese el evento.

Tipos [referencia]
  • Modelo de transmisión: un evento se transmite a todos los objetos de la aplicación. El objeto que puede manejar el evento puede adquirir el control.
  • Modelo impulsado por interrupciones: habrá un controlador de interrupciones para procesar la interrupción y pasar a algún objeto para procesarla.
Ventajas
  • Es fácil de entender.
  • Aunque hay un coordinador externo, los objetos se pueden hacer más inteligentes para saber qué se supone que deben hacer y se pueden reutilizar en otras aplicaciones.
  • Los coordinadores delegados tienden a conocer menos objetos que los controladores dominantes.
  • Los diálogos son de nivel superior.
  • Es fácil de cambiar, ya que los cambios suelen afectar a menos objetos.
  • Es más fácil dividir el trabajo de diseño entre los miembros del equipo.
Desventajas
  • Demasiada distribución de responsabilidades puede dar lugar a objetos débiles y colaboraciones débiles
Cuándo usar

Cuando se quiere delegar el trabajo a objetos más especializados.

Estilo de control agrupado [ editar ]

Este estilo de control es una variación del estilo de control centralizado en el que el control se factoriza entre un grupo de objetos cuyas acciones están coordinadas. [19] La principal diferencia entre un estilo de control en clúster y delegado es que en un estilo de control en clúster, los objetos de toma de decisiones se ubican dentro de un centro de control mientras que en un estilo de control delegado están en su mayoría afuera. [20]

Estilo de control disperso [ editar ]

Un estilo de control disperso no contiene ningún centro de control. La lógica se extiende a toda la población de objetos, manteniendo cada objeto pequeño y construyendo el menor número posible de dependencias entre ellos. [21]

Ventajas
  • Ninguno
Desventajas
  • Cuando desee saber cómo funciona algo, debe rastrear la secuencia de solicitudes de servicios en muchos objetos.
  • No muy reutilizable porque ningún objeto aporta mucho
Cuándo usar

Nunca.

Estilo de control preferido [ editar ]

Después de extensos resultados de experimentos realizados, solo la alta dirección tiene las habilidades necesarias para hacer uso del estilo de control delegado y el estilo de control centralizado beneficia a los programadores. No se menciona ningún contexto sobre los empleados de nivel medio. [17]

Referencias [ editar ]

  1. ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). "Diseño orientado a objetos: un enfoque basado en la responsabilidad". Avisos ACM SIGPLAN . 24 (10): 74. doi : 10.1145 / 74878.74885 .
  2. ^ 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 . págs. 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 explicación impulsada por 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. ↑ a b c d e Wirfs-Brock y McKean , 2002 , págs. 3
  6. ^ Wirfs-Brock y McKean 2002 , págs. 58
  7. ↑ a b c Wirfs-Brock y McKean , 2002 , págs. 61
  8. ↑ a b Wirfs-Brock y McKean , 2002 , págs. 72
  9. ↑ a b Wirfs-Brock y McKean , 2002 , págs. 17
  10. ↑ a b Wirfs-Brock y McKean , 2002 , págs. 126
  11. ↑ a b c Wirfs-Brock y McKean , 2002 , págs. 168
  12. ^ Wirfs-Brock y McKean 2002 , págs. 340
  13. ↑ a b c d e Wirfs-Brock y McKean , 2002 , págs. 4
  14. ↑ a b c d e f Wirfs-Brock y McKean , 2002 , págs. 93
  15. ↑ a b c Wirfs-Brock y McKean , 2002 , págs. 165
  16. ^ Wirfs-Brock y McKean 2002 , págs.164
  17. ^ a b Eric, Arisholm; Dag IK, Sjoberg (2004). "Evaluación del efecto de un estilo de control delegado versus centralizado sobre la mantenibilidad del software orientado a objetos". Transacciones IEEE sobre ingeniería de software . 30 (8): 521–534. doi : 10.1109 / TSE.2004.43 .
  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ágs.30

Bibliografía [ editar ]

  • Diseño orientado a objetos: un enfoque impulsado por la responsabilidad . En Actas de la conferencia sobre sistemas, lenguajes y aplicaciones de programación orientada a objetos (Nueva Orleans, Luisiana, Estados Unidos, 2 al 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.