Dealing with Roles

Anyone who runs a company deals with other companies. Such companies may act as suppliers of goods or services, they may be customers of your products, they may act as agents for selling goods to your customers, they may be regulatory agencies who you have to deal with to stay on the right side of the law. People may do many things within a company. You have engineers, salesmen, directors, accountants, any of which may need different features in the computer systems within your organization. Dealing with these situations is one of the most common situations in modeling. You have a group of objects which exhibit bunches of common behavior. They don’t all have the same behavior, but they may have some common behavior. At first glance it sounds like a classic case for inheritance, but there are complications. An object might exhibit more than one bunch of behaviors, or may take on new bunches during its lifetime. You may have an agent who is also a customer, you have an accountant who becomes an engineer. This paper is an analysis patterns paper, hence I’m looking at the alternatives from a conceptual point of view, rather than an implementation point of view. I’m asking how we represent our view of the world in our software, and I’m not looking at important implemenation issues such as performance, distribution, concurrency etc. I’ve provided some code samples, but they are there to illustrate the conceptual ideas rather than as statements of what the implementation should look like. The biggest consequence to this is that I’m concentrating much more on interface than on implementation. You will notice that in particular when you compare the use of State Object and Role Object. The implementation is essentially the same, the difference is all about interface. I’ve divided up how to deal with roles into five broad categories. If most of the objects have the same behavior with few variations, then you can use just one type to handle all of them ( Single Role Type).Conversely if they are very different and have no common behavior then just treat them all as seperate types ( Separate Role Type). These are the simple cases, and often they are the right decision.