I have an entity called Member. Members fall into multiple types. Some types are below.

  • Supporter
  • Volunteer
  • Sponsor
  • Player

I can create class for each type and inherit from the base Member entity. But when a Member has more than 1 type in a given time, it is not the right way.

can I use decorator pattern to achieve this intent? Or what the best pattern to get this work?


Language I use is C#

Also different Member types can have additional methods, for example, Sponsor can have its own methods as Donate(), Or the Volunteer can have a method Subscribe() and so on. these thing have to be considered.

  • 1
    Does each role have differing methods associated with them? Or will they all use the same methods but just come under a different type? i.e. all types share the same methods and properties? Feb 5, 2013 at 7:58
  • 1
    There are some common methods that are agreed by all types and may have 0..n specific methods to each. The member is intended to load by given UserID to the factory method. The loaded object should determine what are the types this member object satisfies..
    – Muneer
    Feb 5, 2013 at 8:07

4 Answers 4


As usual, there are several different ways. Here are a few possible ideas for you to investigate:


I would not realize this via inheritance - especially not if you want multiple such roles for a member. Even with just one role, there's the composition over inheritance principle that tells you to avoid doing that if possible. It reduces your potential for reuse dramatically. Anyways, with your requirement that you want to be able to support multiple roles for a member, you would have to provide subclasses for each combination, which results in an exponential explosion of class combinations. Not very feasible.


As you pointed out the decorator pattern would be one possible way, but would still require a lot of work in wrapping the original Member and providing all of its methods via the decorated object as well.


Composition is a straightforward way that you could use to add a role to a Member, if you can define a common interface for the roles, i.e., Supporter, Volunteer, etc. would implement the interface MemberRole and the Member class gets an attribute of type MemberRole (or a list thereof).

If, however, the roles each have different methods, composition doesn't work so well anymore (f.ex. a Supporter has support(), but a Player has play()), because you cannot find a common interface for the roles.


As you didn't tell us which programming language you want to use, let me add one more option that would be interesting, but harder to realize in some languages. As an example, consider Scala with its support for traits. They are a perfect match for your problem, as you could do the following:

trait Supporter {
  def support = ...
trait Player {
  def play = ...
// and so on

val memberA = new Member with Supporter with Player
memberA.support // works fine
memberA.play // works fine
val memberB = new Member with Supporter
memberB.support // works fine
memberB.play // won't compile

Composing traits like this essentially saves you the exponential explosion mentioned above, as you do not need to provide a specific class for a MemberSupporterPlayer and such. An additional advantage is the type-safety shown above that ensures you cannot call methods from a role that your member does not possess.

For something similar in C# you can consider Mixins. See for example the remix project for this. They essentially allow the same kind of composition, but of course use a different syntax.

  • 1
    Thanks for the explanation. My language is C#, let me read through your answer first.
    – Muneer
    Feb 5, 2013 at 6:32
  • 1
    I learnt, there is no support for trait in C# and new release of PHP 5.4 supports it. Is there any other proven way in C# to accomplish this?
    – Muneer
    Feb 5, 2013 at 7:33
  • 1
    How about implementing the trait in C#?
    – Muneer
    Feb 7, 2013 at 8:24
  • 1
    Check the remix project. Trait and Mixin are really just different names for the same thing.
    – Frank
    Feb 7, 2013 at 9:46

Even with unique methods in each role, you can use Composition. You could use Member that has multiple Roles and use Visitor pattern to access their unique methods.

  • 1
    how can I check whether a member belongs to a particular type?
    – Muneer
    Feb 5, 2013 at 11:11
  • 1
    You don't check the type, you send him Visitor (object with method for each type) and it will call the right method. See en.wikipedia.org/wiki/Visitor_pattern
    – user470365
    Feb 6, 2013 at 8:21
  • 1
    I am not much familiar with Visitor Patter. Let me have a look that how it can help me.
    – Muneer
    Feb 6, 2013 at 9:54

I would definitely not use a decorator pattern, because I can hardly see how it corresponds to the domain model.

But what is the domain? It sounds like it is a list of members in a sports club or similar. Why do you track which types of members? Is it purely for keeping the information in a member database, or do you actually use that information in some kind of calculation?

If you are not actually using the information, then you don't need some kind of polymorphic approach. You should simple create Boolean properties on the Member class, IsSupporter, IsVolunteer, etc.

However, if you actually use this for something, you might need a polymorphic approach. I think that the fact that a member can be of several types indicate that there is a hidden domain concept, such as a Role.

A Member should then have multiple roles. A Member method, whose implementation would depend on the role, should probably be implemented by making a similar call to all the roles in the member.

But more information on the domain could lead to a better answer.

  • 1
    Yes @Pete, as you say I can use IsSupporter(), IsVolunteer() and so on. As is in my implementation, each member should be loaded using a common property 'MemberID' through a factory method. The returned object should have the valid class that represent the all types (class) that the member belongs to. If you see, 'Sponsor' must have a special function called "Donate()", then 'Volunteer' should have special function called "SubscribeTo()" and so on. How would I address these problem?
    – Muneer
    Feb 6, 2013 at 6:31
  • 1
    @Muneer - I suggest you add the information about Donate() and SubscribeTo() to the original question. It would make it easier for others to come with a useful suggestion.
    – Pete
    Feb 6, 2013 at 9:44
  • 1
    You are right. I will do it now.
    – Muneer
    Feb 6, 2013 at 9:53

I would question the need to require a single "Member" class (and one only) to represent each person uniquely. Is it likely (or even possible) for a Member to be acting as a Volunteer and Sponsor and it matters that they are the same object instance in the code? In the example you are using, it is perfectly legitimate to have an instance of a Volunteer and a separate instance of a Sponsor, even if they are the same person in real life.

Also, you say the different roles have different method names/functionality. Thus, in order for the Liskov-Substitution principle to apply, the using code would only call methods on the "Member" interface. So either the Member class would have to have some generic method name like "DoYourBehavior" and the derived class knows to call "Play/Donate" OR inheritance doesn't really apply; other than for getting reuse of common code.

Thus, I would treat each role as a separately instantiated class instance and any common functionality can be shared either through inheritance, composition or neither. The key being that there is no reason that the design has to explicitly switch a single class instance between different roles.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.