Cualquier persona que dirige una empresa se dedica a otras empresas.

Estas empresas pueden actuar como proveedores de bienes o servicios, que pueden ser clientes de sus productos, que pueden actuar como agentes para la venta productos a sus clientes, pueden ser los organismos reguladores que tiene que hacer frente a permanecer en el lado derecho de la ley. La gente puede hacer muchas cosas dentro de una empresa. Usted tiene Ingenieros, vendedores, administradores, contadores, cualquiera de los cuales pueden necesitar diferentes caractersticas en los sistemas informticos dentro de su organi aci!n. Lidiar con estas situaciones es una de las situaciones ms comunes en el modelado. Usted tiene un grupo de ob"etos que presentan racimos de comportamiento comunes. #o todos tienen el mismo comportamiento, pero pueden tener un comportamiento com$n. % primera vista parece un caso clsico de la herencia, pero hay complicaciones. Un ob"eto puede e&hibir ms de un mont!n de conductas, o pueden tomar en racimos nuevos durante su vida $til. Usted puede tener un agente que es tambi'n un cliente, tiene un contador que se convierte en un ingeniero. Este documento es un documento de anlisis de los patrones, por lo que estoy mirando las alternativas de un marco conceptual punto de vista, en lugar de un punto de vista de aplicaci!n. (e estoy preguntando c!mo representamos a nuestra visi!n del mundo en nuestro soft)are, y no estoy mirando a cuestiones importantes como Implementaci!n como el rendimiento, distribuci!n, etc concurrencia que he proporcionado algunos e"emplos de c!digo, pero son all para ilustrar las ideas conceptuales ms que como e&presi!n de lo que la aplicaci!n debe ser similar. La mayor consecuencia de esto es que me estoy concentrando mucho ms en la interfa que en su aplicaci!n. Usted se dar cuenta de que, en particular cuando se compara el uso de Estado de ob"etos y de ob"etos de papel. La aplicaci!n es esencialmente el mismo, la diferencia es sobre la interfa . *e dividido la manera de hacer frente a los papeles en cinco grandes categoras. +i la mayora de los ob"etos tienen el mismo comportamiento con pocas variaciones, a continuaci!n, puede utili ar un solo tipo de mane"ar todos ellos ,+ingle -ipo de papel.. /or el contrario si son muy diferentes y no tienen un comportamiento com$n a continuaci!n, s!lo tratar todos ellos como tipos distintos ,por separado -ipo de /apel.. Estos son los casos simples, ya menudo son la decisi!n correcta. La complicaci!n viene cuando hay un comportamiento similar y diferente. % menudo, la mayora de los manera obvia de hacerlo es utili ar subtipificaci!n para mostrar los diferentes comportamientos ,/apel +ubtipo.. Esto no significa que necesariamente el uso de subclases y la herencia para su aplicaci!n. Estos son los patrones de anlisis y por lo tanto ms preocupados con los conceptos y las interfaces que con implementaciones. La clave detrs de este patr!n es que los clientes piensan que se trata de un solo ob"eto que tiene varios tipos de variables. Interior de la bandera, 0elegado ocultos, y ob"eto del Estado tres patrones que pueden ayudar a mantener esta ilusi!n. /roporcionar la ilusi!n que hace la vida del cliente ms simple, puede ser bien vale la pena el esfuer o. La ilusi!n no es a menudo vale la pena el esfuer o. En este caso vale la pena tener un ob"eto independiente para cada de los roles, vinculados a un ob"eto de base que une las cosas ,ob"etos de papel.. En algunos casos es me"or pensar en el papel como una relaci!n entre dos ob"etos ,rol de relaci!n.. %l e&aminar estos patrones tambi'n he mencionado un par de otros en el paso. Con los programas 11 intenta evitar hacer un ob"eto si se trata de una instancia de un

tipo. /ero veces que la informaci!n es legtimo que un cliente para utili ar, tal ve por una pantalla 2UI. 3ecuerde que pedir un ob"eto si se trata de una instancia de un tipo es algo diferente de preguntar si se trata de una instancia de una clase, ya que los tipos ,interfaces. y las clases ,implementaciones. pueden ser diferente. E&plcita ('todos del tipo de parmetros y m'todos del tipo de dos formas de obtener esta informaci!n. %s que el tema de los papeles trae consigo varias t'cnicas. Como la mayora de los problemas en el modelado no es ninguna manera el derecho que funciona en todas las situaciones. Este papel le ayudar a destacar las opciones y venta"as y desventa"as de los involucrados. Las opciones de simple %s que hay ingenieros, vendedores, administradores y auditores de la organi aci!n. 4Ests seguro que necesidad de distinguir entre ellos5 Usted necesita su descripci!n de traba"o, o alg$n indicador similar. /or lo tanto, utili ar un $nico tipo de funci!n con un atributo o de cuerda o de alguna descripci!n de las funciones simples tipo. +i no tienen todas las caractersticas significativamente diferentes a ellos, entonces no se preocupe por tratar de para discriminar entre ellos con cualquiera de los otros patrones en este artculo. -ipo de funci!n $nica 4C!mo se representan las numerosas funciones de un ob"eto5 Combina todas las caractersticas de las funciones en un solo tipo Este patr!n est aqu porque he visto a gente hacer todo tipo de cosas que simplemente no es necesario. +u realmente un espacio en blanco 6no hacer nada 7caso, pero que merece una menci!n, porque siempre debe preguntar es esto suficiente5 6. -al ve por el momento no es necesario ning$n otro patr!n, pero est preocupado que la versi!n 8 del sistema tendr que hacer algo en alg$n momento en el futuro. 9ueno, no se preocupe, de"e que hasta ese momento. El beneficio de una realidad tangible de la programaci!n orientada a ob"etos es que que le permite cambiar las cosas con facilidad, as que entonces. -al ve usted no tendr que hacerlo. Incluso si :u' puede encontrar el mundo es muy diferente entonces, y las decisiones que tome ahora no ser vlido. ; este modelo es fcil de migrar a los otros patrones. /or otro lado considerar una situaci!n en la que los ingenieros, vendedores, administradores y contadores. Cada uno de ellos tienen muchas caractersticas diferentes. /uesto que son diferentes que puede hacer tipos diferentes< cada funci!n es independiente de tipo papel. Esto es lo que los desarrolladores han hecho un sinn$mero de antes, y lleva la venta"a que la separa los diferentes tipos, elimina cualquier acoplamiento entre 'stos y permite a las personas para traba"ar en ellos sin enredarse con la preocupaci!n sobre las relaciones entre ellos. /ero hay dos grandes problemas con el papel por separado -ipo< caractersticas duplicado y la p'rdida de integridad. Ingenieros, vendedores, administradores y contadores de todo tipo de persona, y como tales llevar a un mont!n de cosas similares con ellos. Los nombres, direcciones, informaci!n sobre el personal< cualquier cosa que es general a la gente. -odas estas caractersticas se tienen que copiar si han separado -ipo de papel, as que si hay algunos cambios que afectan a estas caractersticas comunes que tienen que locali ar a todas estas copias y se las arreglar todos de la misma manera. Esta tarea tediosa es lo que se supone que la herencia para fi"ar. La p'rdida de la integridad viene cuando nuestro ingeniero =ohn +mith a>ade algunas responsabilidades de gesti!n. +i 'l es un ingeniero y un administrador que tiene que crear ob"etos independientes para cada funci!n, y no podemos decir que se refieren a la p'rdida de la misma persona -al informaci!n es importante si puede haber interacciones entre el ser un ingeniero y de ser un gerente. Esta falta de integridad es un problema sorprendentemente com$n en los sistemas de negocios

que a menudo hace esto con los clientes y proveedores. %tar todo de nuevo "untos de nuevo puede ser bastante complicado. Separa tipo de Rol 4C!mo se representan las numerosas funciones de un ob"eto5 -ratar a cada funci!n como un tipo separado En general no me gusta este modelo, debido a estos dos problemas. +in embargo, usted debe buscar a ver si los problemas son reales. -al ve no hay ning$n comportamiento com$n, tal ve nunca se han ingenieros que son los gerentes ,o es tan raro que no les importa.. +i ese es realmente el caso, entonces este patr!n est muy bien. (e sorprendera si este fuera el caso, sin embargo, en todo, pero un peque>o sistema. 4:u' pasa si usted est buscando a un antiguo sistema en el que hi o esto, y hay que cambiarlo a proporcionar integridad5 En estas situaciones, el ob"eto y los patrones de (erge? Equivalence@ ob"eto de ABo)lerC le puede ayudar. Uso de subtipificacin +i sus ingenieros, vendedores, gerentes y auditores tienen algunas similitudes y algunas diferencias a continuaci!n, una ruta obvia es la de tipificaci!n como en la figura ?. /onga las caractersticas comunes de cada tipo en el supertipo persona, y poner a cada caracterstica adicional de los subtipos en el caso +ubtipo de papel. Este patr!n se adapta bien a nuestra concepci!n habitual de subtipos. Los ingenieros son especiales tipo de persona, cada instancia de ingeniero es una instancia de la persona, los ingenieros de heredar todos los caractersticas de la persona, pero puede a>adir algunas funciones. Una aplicaci!n puede tratar a un grupo de personas a el nivel supertipo si no se preocupa por las caractersticas especiali adas. +i una persona es a la ve un ingeniero y un gestor de entonces es tanto de los subtipos. +i la parte que ms tarde se convierte en un "ubilado que a>adir un "ubilados papel +ubtipo a la fiesta. /apel +ubtipo 4C!mo se representan las numerosas funciones de un ob"eto5 *acer un subtipo para cada funci!n. /onga el comportamiento com$n en el supertipo D0ios mo, oigo los sonidos tristes de programadores orientados a ob"etos gritando. 4:u' he hecho5 %s que su $ltimo par de frases que caus! el problema. Los lengua"es orientados a ob"etos ms importantes han clasificaci!n $nica, esttica, mientras que las penas de ofender requiere una clasificaci!n de m$ltiples y dinmicas. la clasificaci!n individual, dice que un ob"eto puede ser de un solo tipo y heredar el comportamiento de otros tipos. %s, =ohn +mith puede ser ingeniero y por lo tanto heredan las caractersticas de la persona. /ara ser un gestor, as que necesitamos para crear un ingeniero de combinaci!n E tipo de administrador que se multiplican hereda de ambos ingeniero y gerente. +i tenemos muchos subtipos tendremos combinatoria e&plosi!n de estos subtipos combinaci!n F que va a ser un dolor de mane"ar. ($ltiples clasificaci!n significa que s!lo podemos dar a =ohn +mith, el ingeniero y gerente de tipos sin haber alguna relaci!n entre los tipos. clasificaci!n esttica significa que una ve que un ob"eto se da un tipo que no puede cambiar la clasificaci!n de tipo dinmico permitira a un contador para cambiar a convertirse en un ingeniero. %s que desde lengua"es de programaci!n 11 tienen una sola, la mayora de los desarrolladores esttica de clasificaci!n no considerar este modelo como una opci!n. 0e hecho, no es tan corta y seca como eso. %l hacer el anlisis que estamos buscando en la captura de los e&pertos del dominio visi!n del mundo. % continuaci!n, coinciden con esta visi!n de la el mundo a la interfa de

los componentes de nuestro soft)are. /uesto que estamos buscando en la interfa a continuaci!n este enfoque es posible. Gamos a comen ar por ver lo que nuestras interfaces debe ser. -omar el modelo de la Bigura ?. Esta cifra implica el c!digo en el Listado ?. -odo se define en el Listado ? es una interfa . Esto es lo que necesidad de manipular los ob"etos desde el e&terior.

<< codigo >>

En primer lugar voy a mostrar como hacerlo con una bandera interior. En este caso tenemos una clase de persona que implementa todas las cuatro interfaces. /ara cada partici!n de los subtipos que necesitamos para indicar que el subtipo es apropiado en este caso. Los m'todos ne)+alesman, maHe+alesman y is+alesman ,En el Listado @. mostrar c!mo se puede hacer esto. ,/ara estos e"emplos que he llamado la manipulaci!n de tipo utili ando m'todos e&plcitos los m'todos del tipo.. Estos m'todos se pueden agregar a la interfa de la persona. Cuando se trata de las operaciones definidas en la persona que necesitamos para proteger a asegurar que s!lo se invoca en un vendedor, el Listado @ hace con la requireIs+alesman m'todo privado. Cualquier uso de las operaciones en un vendedor de resultados fuera de vendedor en un error de tiempo de e"ecuci!n. E&plcita ('todo del -ipo 4C!mo se refieren al tipo de dinmica de un ob"eto5 Utili ar m'todos con nombre y is-ypename be-ypename 1I de interfa e&plcita no 1I +i un tipo se a>ade la interfa de la superclase debe cambiar La operaci!n es una operaci!n pay%mount polim!rfico, que se define en la persona, pero aplicadas de manera diferente por los subtipos. /odemos aplicar esta definiendo una operaci!n p$blica que es esencialmente una declaraci!n de caso basado en el indicador de tipo. Este tipo de declaraci!n de tipo de caso base es en general una mala idea en el soft)are orientado a ob"etos, pero aqu est muy bien porque est oculto dentro de la persona clase. 0ado que no se pueden utili ar m'todos polim!rficos que utili a la sentencia case interno a imitar ellos. El indicador interno proporciona una aplicaci!n ra onable de este tipo de clasificaci!n ms comple"a. Lo hace, sin embargo, dar lugar a una clase de comple"o que tiene que asumir todos los datos y comportamiento de los subtipos, as como proporcionar las capacidades de selecci!n del m'todo. % medida que estas responsabilidades crecimiento que todos se agrupan en una sola clase< la que puede ser la clase de bestia que se acechar a sus pesadillas. Interior de la bandera 4C!mo se implementa la generali aci!n5 Utilice un indicador interno. *acer la selecci!n del m'todo dentro de la clase 1I +oporta m$ltiples, clasificaci!n dinmica #1 1I La clase de aplicaci!n tiene las caractersticas de todos los tipos que aplica. Otra aplicacin es usar un delegado ocultos. En este caso los datos adicionales y el comportamiento requerido por el subtipo se implementa en una clase separada. Esta clase est oculto, ya que cualquier clase de cliente no lo ve. El software de cliente todava llama a los mtodos de la persona, la clase pers entonces las manos de los mtodos que el delegado cuando sea necesario. Listado muestra cmo se !ace esto para el tipo de administrador. "odos los mtodos p#blicos declarados en la interfa$ de administrador tiene que ser declarada y aplicarse en persona. La

aplicacin de los controles de que el ob%eto de recibir es un gestor, y si es as los delegados la solicitud al &dministrador de ob%etos ocultos.

<<codigo>>
%l usar el delegado oculta de esta manera mover el comportamiento del gestor y datos especficos de el ob"eto gerente. Esto reduce la comple"idad de la clase de persona. +e trata de una diferencia significativa +i el subtipo de papel contiene una gran cantidad de conductas y caractersticas adicionales. La mala noticia es que clase de persona que todava tiene toda la interfa del +ubtipo de papel y tambi'n tiene que ver la selecci!n del m'todo< la decisi!n de si se debe pasar el mensa"e al 0elegado ocultos. 1cultos 0elegado 4C!mo se implementa la generali aci!n5 /onga las caractersticas diferentes dentro de una clase particular, privada. 0elegado mensa"es a este ob"eto cuando sea necesario. 1I +oporta m$ltiples, clasificaci!n dinmica 1I Gariaci!n de comportamiento se separa en el delegado #o 1I ('todo de selecci!n se lleva a cabo por la clase p$blica. /odemos hacer frente a la selecci!n del m'todo de los aspectos del problema utili ando el ob"eto Estado de A2ang de CuatroC. Esto funciona muy bien cuando tenemos algunos subtipos mutuamente e&cluyentes, tales como vendedor de y el ingeniero. Los subtipos son cada uno implementado con ob"etos ocultos. Las clases ocultos se les da un superclase. La clase de persona contiene una referencia al ob"eto superclase. Esto oculta "erarqua tiene ahora la responsabilidad de determinar la selecci!n del m'todo y el tipo de pruebas, y se puede utili ar la herencia y el polimorfismo de hacer esto. Listado de J y K muestran Listado de c!mo podemos utili ar ob"etos de Estado de los vendedores. Los datos y comportamientos se definen en el ob"eto escondido vendedor. El ob"eto superclase ocultos ,=ob*0. proporciona una el comportamiento predeterminado, que es para indicar un error. La persona que proporciona la interfa p$blica en general y los delegados del m'todo en su totalidad al delegado ocultos. G'ase el contraste entre el presente y el gerente en el Listado L, en este caso la persona no hace nada que no sea delegado. La t'cnica funciona especialmente bien para pay%mount, como se muestra en el listado M. En este caso, el ob"eto del estado requiere alguna informaci!n de una persona. Esto se hace por vacaciones 0elegaci!n A9ecHC< pasando a la persona como un argumento cuando la delegaci!n se hace. NNC10EOO 'i desea utili$ar esto con una particin incompleta, es decir, si una persona puede ser ni un vendedor o un ingeniero, pero una persona de vainilla, entonces usted puede !acer (ob)* una clase concreta, o crear una clase null(ob)d para ese caso. Estado de ob"etos 4C!mo se implementa la generali aci!n5 Crear un delegado ocultos para cada subtipo. 0ales un supertipo com$n con defecto comportamiento. La clase p$blica tiene un enlace no nulo para el supertipo. ver A9anda de los CuatroC. 1I +oporta m$ltiples, clasificaci!n dinmica 1IP Gariaci!n de comportamiento se separa en el delegado

1I ('todo de selecci!n se hace por herencia y polimorfismo. #1 1I Un esfuer o para crear *ebo subrayar el tema com#n detrs de todas estas alternativas+ cada aplicacin se encuentra detrs el mismo con%unto de interfaces declaradas en el Listado ,. -odemos cambiar cualquiera de estas implementaciones sin afectar a cualquiera de los usuarios de estas interfaces. "iendo a uso interno de la bandera si no !ay muc!as caractersticas que participan, y oculta *elegado o del Estado Ob%eto si las cosas son ms comple%as. .a que todos la misma interfa$ que puede traba%ar con seguridad el mtodo ms sencillo para empe$ar y cambiar ms tarde cuando empie$a a volverse complicada. En cuanto las funciones en ob"etos separados Una alternativa al papel +ubtipo es utili ar papel de ob"eto. En este caso consideramos ingeniero, vendedor, contador, gerente, y los "ubilados que todas las funciones que el empleado puede "ugar. La persona tiene un multivalor asociaci!n con el papel que el papel de persona es el supertipo de ingeniero, vendedor, contador, gerente, y los "ubilados. Esto, a que se refiere a ACoadC como el patr!n del actorFparticipante, es una t'cnica com$n para estas circunstancias. La aplicaci!n es muy similar a usar el modelo de ob"etos de Estado, la diferencia est en la interfa . Cuando se utili a papel +ubtipo con el Estado de ob"etos, los ob"etos del estado son totalmente oculto por parte del usuario de la clase. /ara encontrar el presupuesto de un gerente de un usuario pide a la persona ob"eto, que luego hace que la correspondiente delegaci!n. Cuando se utili a papel de ob"eto, sin embargo, el usuario pide a la persona ob"eto de su funci!n de administrador, y luego pide que el papel para el presupuesto. En otras palabras, los papeles se conocimiento p$blico. Las funciones se utili a con mayor frecuencia en el estilo de la figura @, donde cada persona tiene un con"unto de ob"etos de papel por sus diversas funciones. Listado Q muestra como persona a>ade y tiene acceso a estas funciones. Comen amos con primero nos encontramos con el papel de vendedor de la persona, entonces, cambia el valor. El papel de ob"eto 4C!mo se representan las numerosas funciones de un ob"eto5 /onga caractersticas comunes en un ob"eto host con un ob"eto independiente para cada funci!n. Los clientes piden el ob"eto de acogida para la funci!n apropiada para utili ar las funciones de un rol. P La e"ecuci!n directa P +i se agrega una nueva funci!n que no tiene que cambiar la interfa del host. M torpe si las funciones tienen restricci!n M E&pone estructura de roles a los clientes del ob"eto host

Bigura @ En este caso !e utili$ado un enfoque diferente para la informacin de tipo. En el listado / !e usado un mtodo is'alesman que se define en la superclase que es falsa y se reempla$a en la subclase. -odra utili$ar el mismo enfoque en este caso. 'in embargo, por causa de la variedad, !e mostrado un enfoque diferente que utili$a un !as"ype parmetros 0'tring1. El enfoque !as"yp tiene la venta%a de que no es necesario cambiar la interfa$ de la funcin de persona o persona que a2adir una nueva funcin. 'us desventa%as son que !ace que la interfa$ menos e3plcito y el compilador no puede comprobar la correccin de los parmetros. -or lo general prefieren la forma e3plcita, sino encontrar la forma con parmetros #til cuando los cambios de interfa$, debido a los nuevos tipos demasiado muc!o que vale la pena el tiempo de compilacin de c!eques. ('todo con parmetros de tipo 4C!mo se refieren al tipo de dinmica de un ob"eto5 Utili ar m'todos de la de has-ype ,class. y ,typenam. be-ype -res nuevos tipos no causan un cambio en la superclase M La interfa es menos e&plcito NN C10E OO Este uso com#n de las funciones realmente no ofrecen el mismo modelo que la 4igura ,. En la 4igura , !ay reglas definidas en cuanto a qu combinaciones de las funciones se pueden utili$ar. *ebe ser uno cualquiera de un vendedor o un ingeniero, y es posible que un administrador, adems. -ara preservar las reglas que tienen dos alternativas. 5na alternativa es cambiar el mtodo de add6ole para comprobar la valide$ de un nuevo papel como en el Listado 7. 5na me%or manera, sin embargo, es modificar la interfa$ de la persona para que la restriccin ms e3plcita como en el listado ,8. NNC10EOO En el tipo de situaci!n aqu, donde no hay demasiado muchos papeles y hay restricciones, tiendo a preferir usar papel +ubtipo. /apel +ubtipo proporciona una interfa simple sola clase. La desventa"a de papel +ubtipo es que la interfa de la persona que tiene que incluir todos los m'todos definidos en los papeles, que es torpe si la interfa de papel es grande o voltiles. +i es difcil de forma continua cambiar el interfa de la persona a continuaci!n, que es la fuer a que me impulsa hacia el papel de ob"eto. En la mayora de las situaciones en que la fuer a est presente el con"unto de funciones de la figura @ tiene ms sentido. Cualquier normas relativas a combinaciones de funciones debe ser capturado< si son simples que utili an la t'cnica del listado R, si son ms comple"os entonces se cambiar la interfa y el uso Listado ?S estilo. En la prctica me parece que las situaciones que impulsan a una interfa de estilo Listado ?S se resuelven me"or con papel +ubtipo de todos modos. 3ecuerde que usted puede utili ar una t'cnica de algunos papeles y otra para otros papeles. Una variaci!n $til sobre este modelo es hacer que los ob"etos de papel de decoradores del ob"eto principal. Esto significa que un cliente que utili a s!lo las caractersticas de la persona que los empleados pueden tratar con un solo ob"eto

y no necesitas saber sobre el uso de ob"etos de papel. El costo es de que cuando alguna ve la interfa de la persona cambia, todos los roles necesitan ser actuali ados. (as A9Tumer et alC para ms detalles sobre c!mo hacer esto. La alternativa final en funciones de modelado que estoy discutiendo en este artculo es el papel de la relaci!n. La necesidad de rol de relaci!n surge cuando se considera una organi aci!n con varios grupos, donde un empleado podra tener papeles en ms de un grupo. Un vendedor puede comen ar con un grupo, el cambio a otro, la "ubilaci!n, pero hacer un traba"o para otro. En este caso, en cada funci!n de lo que necesitamos saber no s!lo el papel, sino tambi'n que el 2rupo de los empleados mantiene el papel con. Usted puede pensar en el papel de una relaci!n laboral entre el empleado y el grupo. -an pronto como empie as a pensar de una funci!n como la relaci!n del patr!n de rol de relaci!n de la Bigura P comien a a tener sentido.. Uso y aplicaci!n de rol de relaci!n es bastante similar a la funci!n de ob"eto ,v'ase el Listado ??., la principal diferencia est en el hecho de que la creaci!n y el acceso a las funciones de las necesidades de un grupo como parmetro. +i hay restricciones entre los papeles, entonces usted puede utili ar las mismas t'cnicas que con el papel de ob"eto. Rol de relacin 4C!mo se representan las numerosas funciones de un ob"eto5 *aga que cada papel una relaci!n con un ob"eto apropiado -res naturales si el ob"eto servidor puede tener ms de una funci!n en relaci!n con otro ob"eto. Una situaci!n com$n con este patr!n es que la funci!n de cambiar la relaci!n con el tiempo, y una historia de estos cambios debe mantenerse. -ambi'n puede haber normas que indican qu' tipo de personas pueden tener que tipo de rol de relaci!n con diferentes tipos de grupos. 3endici!n de cuentas y patrones relacionados en ABo)lerC discuten este tipo de furthe complicaciones. 4:u' papel elegir +iempre que tenga una situaci!n que involucra a las funciones, no olvide que usted tiene varias opciones para elegir en el modelado de la misma. +i el papel significativamente diferente5 +i las diferencias son menores que los de un solo uso tipo de funci!n. ;o no, %1- preocuparse por no ser lo suficientemente fle&ible. +i necesita la fle&ibilidad ms adelante, es fcil refactori ar. 4*ay comportamientos comunes entre los papeles5 +i no me podra ir por separado -ipo de /apel. ;o, %1( siempre cuidadoso de la cuesti!n integrety sin embargo. Este patr!n puede ser ms difcil de cambiar ms adelante si surge. +!lo si s' que tienen un comportamiento significativo com$n y compartida, y tengo que velar por integrety tengo que ir a las opciones de peso pesado. %qu a menudo la decisi!n clave es entre 3ol +ubtipo y ob"eto de funci!n. (uchos autores le dir que utili ar siempre papel de ob"eto, yo no, %1- de acuerdo. La pregunta clave que pido es 4cul es la me"or interfa para los usuarios de mis clases5 -res indicadores sugieren /apel +ubtipo< #o hay vino, papeles aot demasiadas, las nuevas funciones no aparecen a menudo, y hay normas importantes sobre lo que las combinaciones y las migraciones de los roles que pueden ocurrir. +i esas fuer as estn presentes entonces voy con papel +ubtipo. 0e esta forma se presenta un interfa ms sencilla. ;o tomar esa decisi!n, y luego elegir la forma de ponerla en prctica. La aplicaci!n es un poco ms duro que papel de ob"eto, pero, %1( ahorro de mis clientes la

misma cantidad de traba"o. /uesto que hay muchos de ellos, que puede ser un favor considerable. ;o elegira al papel de ob"eto o tengo un mont!n de papeles, o menudo me nuevos roles. Estas fuer as que conducen a una interfa de gran tama>o o voltiles para un subtipo de funciones. En este punto, sera demasiado traba"o para mantener el +ubtipo de papel. Considero que el rol de relaci!n que roleness, %1( interesa es todo acerca de una relaci!n entre el ob"eto principal y alg$n otro ob"eto. Esto es particularmente cierto si el ob"eto central puede "ugar el mismo papel con muchos otros ob"etos, o si desea reali ar un seguimiento de los cambios a las funciones que el ob"eto central "uega con el tiempo. Un papel con muchos "ugadores -odos estos modelos de hacer una suposici!n com$n, que un papel es algo que desempe>a un ob"eto de un solo n$cleo dentro de un conte&to. /ero este supuesto no es cierto de todas las situaciones que sugieren funciones. Cuando el anillo de un avi!n a una reserva, estoy buscando someon) para desempe>ar el papel de reserva para m, pero no me importa que la persona que desempe>a. En esta situaci!n, el papel es el elemento clave, pero la persona es irrelevent. (e puede llamar tres veces sobre la misma reserva y por lo general tendr una persona diferente cada ve . En esta situaci!n que por lo general no saben mucho sobre el papel. Una situaci!n algo diferente aparece cuando se han consistente en curso negociaciones con un papel donde suele haber un ob"eto de un solo n$cleo, pero cambia con el tiempo. Esto puede ocurrir cuando se traba"a con un vendedor regional de su ona. El %(9I1+ persona real, pero el papel sigue siendo el mismo. Una ve ms el papel es ms importante para usted que la persona. #o voy a discutir estas situaciones en el presente documento, por lo menos no hasta que una versi!n posterior. -engo que pensar ms acerca de los patrones que he visto de este tipo de problemas. El $ltimo caso ,un papel con muchos actores en el tiempo. puede ser modelado utili ando el /ost patr!n Bo)lerC. En resumen Escrib este artculo porque me senta frustrado. Esta frustraci!n es buena fuente para los patrones. % menudo es la frustraci!n de ver a la gente hacer el mal tiempo lo mismo una y otra ve . En este caso, la frustraci!n se debe a la gente que utili a uno de estos patrones todo el tiempo, y condenan a los dems. #o me opongo a cualquier de estos patrones F lo que me opongo a que es una prctica de utili ar uno de ellos todo el tiempo. El dise>o es todo acerca de las compensaciones, y cada uno de estos modelos viene con su propio sistema de compensaciones. Cualquiera de los patrones en este documento puede ser el modelo adecuado para su problema. la adhesi!n dogmtica a un patr!n no es la respuesta, usted tiene que entender una evaluaci!n de las venta"as y desventa"as. Esta verdad es eterna en el dise>o. Lecturas Los roles han sido durante mucho tiempo una t'cnica conocida con el ob"eto y C1(U#I0%0E+ modelado de datos. Consider' escribir sobre ellos en los patrones de anlisis ABo)lerC, pero consider! el tema demasiado trivial ,Como decir los n$meros pueden apoyar la aritm'tica.. *e cambiado de opini!n tan a menudo porque la gente se describe uno de estos patrones ,sobre todo de ob"etos de papel. como la $nica soluci!n sin hablar de la serie completa de soluciones de compromiso. /or lo tanto no e&iste un tratamiento real de los su"etos en los patrones de anlisis, a e&cepci!n de la discusi!n de la 3endici!n de Cuentas ,@.L. que es un uso de rol de relaci!n.

A9Tumer et alC, establece una discusi!n en profundidad de la aplicaci!n de ob"etos de papel. +u enfoque hace el papel de un ob"eto A9anda de los CuatroC decorador del ob"eto base. Esto significa que los clientes pueden tratar con el ob"eto de papel sin saber que el ob"eto base es en realidad un ob"eto independiente. +i eso ayuda a simplificar las cosas para el cliente, es una tctica $til. A2amma, E&tensi!nC se describe un modelo para la ampliaci!n del ob"eto comportamiento mediante un enfoque similar a la de ob"etos de papel. La soluci!n es similar a la de papel de ob"etos sino a la intenci!n es algo diferente. El patr!n de e&tensi!n se trata principalmente de hacer frente a cambios no anticipados a un servicios de los ob"etos, mientras que el modelo de ob"etos de papel es ms sobre c!mo tratar con un ob"eto de "uego muchas funciones distintas. A+choenfeldC se describe un par de usos del papel de ob"etos con las personas y de los documentos. A*ayC tiene muchos e"emplos de problemas de modelado de papel tratado con un sabor relacional. ACoadC describe el modelo de actorF/artcipant, que es esencialmente de ob"etos de papel, y da muchos e"emplos de su uso. 0ebo mencionar que una referencia adecuada a todos los que ha discutido el uso de funciones que consumen ms pginas de este documento. Uso de funciones de una manera u otra es para el modelado lo If-hen else estn a la programaci!n. /or lo tanto hay mucho que se ha escrito sobre el tema, por lo general en un offFhaba forma que es caracterstico cuando la gente escribe sobre muy conocido construcciones. (is disculpas a toda la gente que poda haber hecho referencia aqu, pero no lo hi o.