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.

A good object-oriented design involves an early focus on behaviors to realize the capabilities meeting the stated requirements and a late binding of implementation details to the requirements. This approach especially helps to decentralize control and distribute system behavior which can help manage the complexities of high-functionality large or distributed systems. Similarly, it can help to design and maintain explanation facilities for cognitive models, intelligent agents, and other knowledge-based systems.[3]

Building blocks

In their book Object Design: Roles, Responsibilities and Collaborations,[4] the authors describe the following building blocks that make up responsibility-driven design.

  • Application: A software application is referred to as a set of interacting objects.[5]
  • Candidates: Candidates or candidate objects are key concepts in the form of objects described on CRC cards. They serve as initial inventions in the process of object design.[6]
  • Collaborations: A collaboration is defined as an interaction of objects or roles (or both).[5]
  • CRC Cards: CRC stands for Candidates, Responsibilities, Collaborators. They are index cards used in early design for recording candidates.[7] These cards are split up into an unlined and a lined side.
    • Content of lined side: On this side the candidate's name, its responsibilities and its collaborators are recorded.[7]
    • Content of unlined side: On this side the candidate's name, its purpose in the application, stereotype roles and anything worthwhile such as the names of roles in patterns it participates in are recorded.[7]
  • Hot Spots: Hot Spots are points in the application where variations occur. They are recorded using Hot Spot Cards.[8]
  • Hot Spot Cards: Hot Spot Cards are used for recording variations with just enough detail so you can discriminate important difference. Similar to CRC cards, these are also created from index cards.[8] These cards consist of:
    • Hot Spot Name
    • General description of the variation
    • At least two specific examples where the variation occurs

Objects

Objects are described as things that have machine-like behaviors that can be plugged together to work in concert. These objects play well-defined roles and encapsulate scripted responses and information.[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: Estas 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.