Dealing with Roles

Martin Fowler
fowler@acm.org


Cualquier persona que dirige una empresa se ocupa de otras empresas. Estas empresas pueden actuar
como proveedoras de bienes o servicios, pueden ser clientes de sus productos, que pueden actuar como
agentes de venta de mercancas a sus clientes, que pueden ser las agencias reguladoras que usted tiene
que hacer frente para permanecer en el lado derecho de la ley.

La gente puede hacer muchas cosas dentro de una empresa. Usted tiene ingenieros, vendedores,
directores, contadores, cualquiera de los cuales pueden necesitar diferentes caractersticas en los
sistemas informticos dentro de su organizacin.

Hacer frente a estas situaciones es una de las situaciones ms comunes en el modelado. Tiene un grupo
de objetos que exhiben racimos de comportamiento comn. Ellos no todos tienen el mismo
comportamiento, pero pueden tener un comportamiento comn. A primera vista suena como un caso
clsico de la herencia, pero hay complicaciones. Un objeto podra mostrar ms de un montn de
comportamientos, o puede asumir nuevos racimos durante su vida til. Usted puede tener un agente
que es tambin un cliente, usted tiene un contador que se convierte en un ingeniero.

Este documento es un documento de pautas de anlisis, por lo tanto, estoy mirando las alternativas
desde el punto de vista conceptual, en lugar del punto de vista de la implementacin. Me estoy
preguntando cmo nos representamos a nuestra visin del mundo en nuestro software, y yo no estoy
mirando las cuestiones de aplicacin importantes como el rendimiento, la distribucin, la simultaneidad,
etc. Que he proporcionado algunos ejemplos de cdigo, pero ellos estn ah para ilustrar las ideas
conceptuales ms que como expresin de lo que la aplicacin debera ser. La mayor consecuencia de
esto es que me estoy concentrando mucho ms en la interfaz de la implementacin. Te dars cuenta, en
particular cuando se compara el uso de objetos de Estado y el papel de objeto. La aplicacin es
esencialmente la misma, la diferencia es todo acerca de la interfaz.

He dividido cmo lidiar con roles en cinco grandes categoras. Si la mayora de los objetos tienen el
mismo comportamiento, con algunas variaciones, entonces usted puede utilizar un solo tipo para
manejar todos ellos (Tipo nico de Rol). Por el contrario, si son muy diferentes y no tienen un
comportamiento comn a continuacin, simplemente tratamos todos los tipos como separados (Tipo de
rol independiente). Estos son los casos simples, y con frecuencia son la decisin correcta.

La complicacin viene cuando hay algn comportamiento similar y alguno diferente. A menudo, la forma
ms obvia de hacer esto es utilizar subtipos para mostrar los diferentes comportamientos (subtipo de
funciones). Esto no quiere decir que se utiliza necesariamente la creacin de subclases y la herencia para
implementarlo. Estos son los patrones de anlisis y por lo tanto ms preocupados con los conceptos y
las interfaces que con implementacin. La clave detrs de este patrn es que los clientes piensan que se
trata de un objeto nico que tiene varios tipos cambiables. Internal Flag, Hidden Delegate, and State
Object son tres patrones que pueden ayudar a mantener esta ilusin. Proporcionar esta ilusin hace que
la vida del cliente sea ms simple, puede bien valer la pena el esfuerzo.

La ilusin a menudo no vale la pena el esfuerzo. En este caso vale la pena tener un objeto separado para
cada uno de los roles, vinculado a un objeto de base que une cosas juntas (Role Object). En algunos
casos, es mejor pensar en el rol como una relacin entre dos objetos (Role Relationship). Explicit Type
Method (Mtodo de tipo explicito) and Parameterized Type Method (Mtodo de tipo parametrizado)
son dos formas de obtener esta relacin.

As que el tema de los roles trae consigo varias tcnicas. Como la mayora de los problemas en la
modelizacin no hay manera correcta que funcione en todas las situaciones. Este trabajo ayuda a
sealar las opciones y las ventajas y desventajas involucradas.




Problema Solucin Patrn P









Cmo se representa
los mltiples roles de un
objeto?
Combina todas las
caractersticas de las
funciones en un solo tipo

Single Role Type
4
Tratar a cada rol como un tipo
separado

Separate Role Type
4
Hacer un subtipo para cada
rol. Ponga comportamiento
comn en el supertipo

Role Subtype
5
Ponga caractersticas
comunes en un objeto host
(sede) con un objeto
independiente para cada rol.
Los clientes solicitan al objeto
host por el rol apropiado para
utilizar las caractersticas de
dicho rol.




Role Object
14
Haga que cada rol de una
relacin con un objeto
apropiado

Role Relationship
17

Tabla 1: Tabla de patrones





Problema Solucin Patrn P






Cmo se implementa la
generalizacin?
Utilice un indicador interno. Realice la
seleccin del mtodo dentro de la clase

Internal Flag
8
Ponga las caractersticas que varan dentro
de una clase separada y privada. Delegue
mensajes a este objeto cuando sea
necesario.


Hidden Delegate
10
Crea un delegado oculto para cada subtipo.
Dales un supertipo comn con el
comportamiento predeterminado. La clase
pblica tiene un enlace que no sea nulo para
el supertipo. ver [Gang of Four].




State Object
13


Cmo no referirse al tipo
dinmico de un objeto?
Utilice mtodos denominados isTypenam y
beTypename
Explicit Type
Method
8
Utilizar mtodos de la forma hasType
(nombre de tipo) y beType (nombre de tipo)
Parameterized
Type Method
14

Tabla 1: Tabla de patrones







Las Opciones Simples
As que hay ingenieros, vendedores, gerentes y contadores en su organizacin. Qu es lo que usted
realmente necesita para diferenciarlos entre ellos? Usted necesita su descripcin de trabajo, o algn
indicador similar.
Por lo tanto, use un Single Role Type (nico tipo de rol) con un atributo, ya sea un String o algn tipo
simple de descripcin del trabajo. Si no tienen caractersticas muy diferentes entre ellos, entonces no se
preocupe por tratar de discriminar entre ellos con cualquiera de los otros patrones en este artculo.



Single role type
Cmo representar los mltiples roles de un objeto?
Combina todas las caractersticas de los roles en un solo tipo


Simple
Conduce a un solo tipo complejo




Este patrn est aqu porque he visto que la gente hace todo tipo de cosas que simplemente no son
necesarias. Es realmente un caso en blanco "no hacer nada", pero que merece una mencin porque
siempre se debe preguntar "Es esto suficiente? '. Quizs por el momento no es necesario ningn otro
patrn, pero le preocupa que la versin X del sistema tendr que hacer algo en algn momento en el
futuro. Pues no te preocupes, djalo hasta entonces. El nico beneficio muy tangible de la programacin
orientada a objetos es que le permite cambiar las cosas con facilidad, as que hazlo despus. Tal vez
usted no tendr que hacerlo. Incluso si lo hace es posible que el mundo se vea muy diferente entonces,
y las decisiones que tome ahora lo invlidaran. Y este patrn es fcil de migrar a los otros patrones.
Pero hay dos grandes problemas con Separate Role Type: funciones duplicadas y la prdida de la
integridad. Los ingenieros, vendedores, gerentes y contadores son todo tipo de persona, y como tales
tienen una gran cantidad de cosas similares con ellos. Nombres, direcciones, informacin sobre el
personal: todo lo que es de carcter general a las personas. Todas estas caractersticas tendrn que
copiarse si tiene Separate Role Type, por lo que si hay algn cambio que afecta a estas caractersticas
comunes se tiene que localizar a todas esas copias y solucionarlos todos de la misma manera. Esta tarea
tediosa es lo que se supone que la herencia arregla.
La prdida de la integridad viene cuando nuestro ingeniero John Smith aade algunas responsabilidades
de gestin. Si l es a la vez un ingeniero y un gerente tenemos que crear objetos separados para cada
rol, y no podemos decir que se refieren a la misma persona la prdida de dicha informacin es
importante si hay interacciones mientras se es un ingeniero y se es un gerente. Esta falta de integridad
es un problema sorprendentemente comn en los sistemas de negocios que a menudo hacen esto con
los clientes y proveedores. Atar todo junto de nuevo puede ser bastante complicado.









Separate role type
Cmo representar los mltiples roles de un objeto?
Tratar a cada papel como un tipo separado


Simple
Cualquier comportamiento compartido debe ser duplicado
Difcil de tratar con un solo objeto que juega muchos roles




En general no me gusta este patrn, debido a estos dos problemas. Pero usted debe buscar para ver si
los problemas son realmente estos. Tal vez no hay un comportamiento comn, tal vez usted nunca
tendr los ingenieros que son gerentes (o es tan raro que usted simplemente no les importa). Si ese es
realmente el caso, entonces este patrn est bien. Me sorprendera si este fuera el caso, sin embargo,
en todo, pero un pequeo sistema. Estara sorprendido si este fuere el caso, de todos modos, en
cualquiera menos un sistema pequeo.
Qu pasa si usted est buscando en un sistema heredado, donde ellos hicieron esto, y hay que
cambiarlo para proporcionar integridad? En estas situaciones, los patrones de objetos Merge1 y objetos
Equivalence2 de [Fowler] puede ayudarle.


Usando subtipificacin
Si sus ingenieros, vendedores, gerentes y contadores tienen algunas similitudes y algunas diferencias
entonces una ruta obvia es la de subtipos como en la Figura 1. Ponga las caractersticas comunes de
cada tipo en el supertipo persona, y ponga cada caracterstica adicional de los subtipos en el Subtipo Rol
(Role Subtype) apropiado. Este patrn se ajusta bien a nuestra concepcin habitual de subtipos. Los
ingenieros son un tipo especial de persona, cada instancia de ingeniero es una instancia de la persona,
los ingenieros heredan todas las caractersticas de la persona, pero pueden aadir algunas
caractersticas. Una aplicacin puede tratar a un grupo de personas a nivel supertipo si no se preocupa
por las caractersticas especializadas. Si una persona es a la vez un ingeniero y un gerente, entonces es
de ambos subtipos. Si la persona ms tarde se convierte en un jubilado tenemos que agregar una
funcin Subtipo jubilado a la persona.



Role Subtype
Cmo representar los mltiples roles de un objeto?
Hacer un subtipo para cada rol. Poner el comportamiento comn en el supertipo


Conceptualmente simple
Interface simple
No se puede aplicar directamente si existen mltiples o cambio de roles
Cada nuevo papel hace que la interfaz del supertipo cambie




Dios mo , oigo los sonidos tristes de programadores orientados a objetos gritando. Qu he
hecho?
Bien, es que el ltimo par de frases ha causado problemas. Los principales lenguajes OO
tienen una simple, clasificacin esttica, mientras que aquellas sentencias ofensivas requieren
mltiples, clasificacin dinmica.
Una clasificacin individual dice que un objeto puede ser de un solo tipo y heredar
comportamiento de otros tipos. As, John Smith puede ser ingeniero y heredar las
caractersticas de una persona.