Creating an object that has all the properties of two other objects?

Consider a sports club situation. A club can have a Club manager and 1 or more Coaches (1 coach per team) So, here is an example of the Manager and Coach classes.

Class ClubManager
{
    public void RegisterMember()
    {
      开发者_开发问答  // code for registering a member..
    }
}

Class Coach
{
    public void DeviceTeamFormation()
    {
        // code for making a team formation..
    }
}

My issue is, how can I have a Club manager who is also a Coach? because there are sports clubs with this situation.

Appreciate any and all help. Thanks guys.

No, you cannot do this with classes. Interfaces however get you in that direction.

On the other hand, you may want to add another level of indirection and separate the manager and coach roles from persons, so that you can assign each role to a person (which may also be the same person).

Lucero's second paragraph is the correct approach. Coach and Manager are not kinds of people, they are roles that people play. Theoretically the same person could be a TeamPlayer, TeamCaptain, Coach, Manager, and WaterBoy!

So what you want is composition, not inheritance. For example:

SportsClub myClub = new SportsClub();
Person Bill = new Person();
myClub.Manager = new Manager(Bill);
myClub.Coach = new Coach(Bill);

Being a Coach and being a ClubManager are not inherent attributes of this person. They are roles that the person has taken on. As such I would say that the person object (or whatever it is you want to call it) should be assigned roles. Those role/ability objects would then delegate those methods.

So it might look like this:

Person joe = new Person("joe");
joe.setClubManager(true);

joe.getManagerAbilities().RegisterMember();

Hard to know what is right without a lot more information about your problem, but maybe this will get you thinking along some different line.

Multiple Inheritance is what you are looking for. Unfortunately, this is not currently supported in C#. I did not see it come up in the 2010 version either.

You can implement multiple interfaces, but you cannot inherit from multiple classes.

As Chinmay Kanchi noted, C# does not support multiple inheritance; however, you can inherit from a type and implement as many interfaces as you like.

public interface ICoach {
}

public class ClubManager : SomeType, ICoach {
}

I would use delegation rather than inheritance and use the Composite Pattern instead. (http://en.wikipedia.org/wiki/Composite_pattern)

you can do this but with following procedure as C# does not support Inheritance through classes

Interface IClubManager 
{
  public void RegisterMember();        
}

Interface ICoach 
{
   // code for making a team formation.. 
}
class SomeDesignation : ICoach, IClubManager 
{
}

As others have noted, you can't do that with classes, although you can do it with interfaces, which has the disadvantage that you have reimplement the interface each time. One way around that is with mixins: Is it possible to implement mixins in C#?.

You can not have exactly what you want - multiple inheritance is not supported in C#.

Along with the other proposals about using interfaces (with their limitations), you can possibly re-think the object model at all.

If you separate your data structure (classes), so the Coach class and the ClubManager class has property Person, they you will not "duplicate" the person's data. And you can have factory methods to create Coach out of person, and/or ClubManager out of person.

Another option would be to have "InRole" functionality, which says what role a person can have, and the Person class will have both methods you require, but each one of them may throw an exception if the person is not in the right role to perform the operation.

Or, you can inject "roles", and use some form of indirection to access the specific role's functionality.

Here's the first idea that popped into my head:

1. Create a ClubManagerCoach class, or something to that effect that has logic for both managers and coaches.
2. Create interfaces for IClubManager and ICoach. Use those interfaces in place of ClubManager and Coach.
3. Make ClubManagerCoach implement IClubManager and ICoach.

I think the best compromise you'll get in this case (and this is a debated topic, of course) is to create something along the lines of a ClubManagerCoach class that exposes ClubManager and Coach properties.