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

Inheritance

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.

Decorator

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

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.

Traits/Mixins

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.

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.

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.

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.