player-role Comparison Table

Object Oriented Software Engineering View all facts Glossary Help

subject > pattern > design pattern > player-role

Next design pattern: proxy Up: design pattern Previous design pattern: observer

player-role comparison table

Subject have solution have related patterns have context have forces have problem has definition have antipatterns is a subtopic of is a kind of is an instance of

design pattern zero or more related design patterns a context one or more forces a sentence or two explaining the main difficulty being tackled A pattern useful for the design of software zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection 6.1 - Introduction to Patterns pattern

player-role
Create a ŤPlayerť class to represent the object that plays different roles.
Create an association from this class to an abstract ŤRoleť class, which is the superclass of a set of possible roles.
The subclasses of this ŤRoleť class encapsulate all the properties and behaviours associated with the different roles.
If the ŤPlayerť can only play one role at a time, the multiplicity between ŤPlayerť and ŤRoleť can be one-to-one, otherwise it will be one-to-many.
Abstraction-Occurrence pattern
A role is a particular set of properties associated with an object in a particular context.
An object may play different roles in different contexts.
it is desirable to improve encapsulation by capturing the information associated with each separate role in a class but you want to avoid multiple inheritance
you cannot allow an instance to change class
How do you best model players and roles so that a player can change roles or possess multiple roles? A pattern in found in class diagrams in which one class (the player) has several associated role classes. Instances of the role classes can change over the lifetime of a player merging all the properties and behaviours into the Player class which however, creates an overly complex class - much of the power of object orientation is lost 6.4 - The Player-Role Pattern design pattern

Subject	have solution	have related patterns	have context	have forces	have problem	has definition	have antipatterns	is a subtopic of	is a kind of	is an instance of
design pattern		zero or more related design patterns	a context	one or more forces	a sentence or two explaining the main difficulty being tackled	A pattern useful for the design of software	zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection	6.1 - Introduction to Patterns	pattern
player-role	Create a ŤPlayerť class to represent the object that plays different roles. Create an association from this class to an abstract ŤRoleť class, which is the superclass of a set of possible roles. The subclasses of this ŤRoleť class encapsulate all the properties and behaviours associated with the different roles. If the ŤPlayerť can only play one role at a time, the multiplicity between ŤPlayerť and ŤRoleť can be one-to-one, otherwise it will be one-to-many.	Abstraction-Occurrence pattern	A role is a particular set of properties associated with an object in a particular context. An object may play different roles in different contexts.	it is desirable to improve encapsulation by capturing the information associated with each separate role in a class but you want to avoid multiple inheritance you cannot allow an instance to change class	How do you best model players and roles so that a player can change roles or possess multiple roles?	A pattern in found in class diagrams in which one class (the player) has several associated role classes. Instances of the role classes can change over the lifetime of a player	merging all the properties and behaviours into the Player class which however, creates an overly complex class - much of the power of object orientation is lost	6.4 - The Player-Role Pattern		design pattern

Next design pattern: proxy Up: design pattern Previous design pattern: observer