The Role Object Aptron

|
Trabajo Final |
Objetos II |
|
|
|

|

Primera Parte:

Traducción
The Role Object Pattern

Role Object Pattern

Intención/ propósito

Adapta un objeto a las diferentes necesidades de un cliente, de manera transparente a través del enlace con objetos rol, cada uno de los cuales representa un rol que el objeto desempeña en el contexto del cliente. El objeto maneja suconjunto de roles dinámicamente. Para representar roles como objetos individuales, los diferentes contextos se mantienen separados simplificando la configuración del sistema.

Motivación

Un sistema orientado a objetos se basa típicamente en un conjunto de claves de abstracción. Cada una es modelada por su correspondiente clase en términos abstractos de estado y comportamiento. Esto funcionausualmente bien para el diseño de pequeñas aplicaciones. Sin embargo, una vez que se quiere escalar el sistema en un conjunto integrado de aplicaciones, debemos lidiar con diferentes clientes que necesitan vistas de contexto específico de cada una de nuestras claves de abstracción.
Supongamos que estamos desarrollando un software para dar soporte al departamento de inversiones de banco. Una delas claves de abstracción se expresará entonces con el concepto de cliente. Por lo que en nuestro modelo de diseño incluirá una clase Customer. La interfaz de esta clase proveerá operaciones para manipular los atributos del Customer tales como el nombre del cliente, dirección, ahorros y cuentas de depósito.
Supongamos que el departamento de préstamos del banco también necesita el apoyo de software.Parece entonces que nuestra clase modelada hasta ahora es inadecuada para permitirle al Customer actuar como prestamista, por ejemplo. Obviamente, debemos proporcionar el estado de aplicación y las operaciones de administrar las cuentas de los clientes de préstamos, créditos y valores.
Integrar muchos contextos específicos en la misma clase Customer conducirá probablemente a que las claves deabstracción de la interfaces queden superpuestas. Tales interfaces serán difíciles de entender y de mantener. Los cambios inesperados deberán ser tratados con cuidado y dispararán muchas re-compilaciones. Los cambios en partes específicas de la interfaz de la clase Customer afectarán probablemente a los Clientes en otros subsistemas y así como también en otras aplicaciones.
Una solución simpletal vez sea extender la clase Customer incorporando las subclases Prestamista e Inversor, que capturarán el contexto específico de Prestamistas e inversores respectivamente. Desde el punto de vista de la identidad del objeto, la sub-clasificación implica que dos objetos de diferentes subclases no son idénticos, por más que pertenezcan a la misma super-clase. Así, un Customer tanto en calidad deinversor, como de Prestamista es representado por dos objetos diferentes con sus respectivas identidades. La identidad solo puede ser simulada con un mecanismo adicional. Si dos objetos no están destinados a ser idénticos, sus atributos heredados deben ser constantemente chequeados para mantener la consistencia. Sin embargo, caeremos inevitablemente en problemas en el caso de búsquedas polimórficas,por ejemplo cuando queramos obtener la lista de todos los Clientes del sistema, un mismo objeto Customer aparecerá repetidamente a menos que nos encarguemos de eliminar los “duplicados”.
Lo que nos sugiere el patrón Rol Object es modelar las vistas de contexto específico del objeto en un objeto de rol por separado, que puede ser dinámicamente asociado o eliminado del objeto principal. Llamamos aesto una estructura de composición de objeto que consiste en el Core y sus diferentes roles. El sujeto juega a menudo varios roles y el mismo rol puede ser probablemente jugado por diferentes sujetos. Como un ejemplo consideremos dos Clientes distintos que son, Borrower e Inversor dentro l banco, respectivamente. Ambos roles pueden ser jugados por un objeto único Customer.

Figura 1: Jerarquía...