views:

140

answers:

11

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.

+1  A: 

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.

Raj More
It isn't something that is ever likely to be added to C# because of all of the pitfalls it creates. http://en.wikipedia.org/wiki/Multiple_inheritance#Criticisms
Nathan Taylor
A: 

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.
Stuart Branham
+8  A: 

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
+1 This is the correct solution; Coach and Manager are ROLES that people play, not kinds of people. More details below.
Steven A. Lowe
+1  A: 

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 {
}
Nathan Taylor
A: 

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.

Dan Tao
+1  A: 

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

Robert Davis
+1  A: 

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 
{
}
Asad Butt
+1  A: 

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: http://stackoverflow.com/questions/255553/is-it-possible-to-implement-mixins-in-c.

Isaac Cambron
+1  A: 

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.

Sunny
+2  A: 

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.

Jason Tholstrup
Your suggestion makes logical sense but I am very new to this concept of roles and this technique i.e. I have never used it in my life.Are you able to give me some suggestions as to where to start on understanding how to use this technique to solve the problem?appreciate it, ty.
fred
Yeah... it's kind of something I pulled out of my ass. Basically I was thinking of mix-in's from Ruby and composition like Robert Davis mentions in here. Roles/abilities seemed like a good way to divide up your problem and fake our way to mix-ins. Basically my thought process was that the people in your system aren't 'coaches'. They are people who sometimes have coaching responsibilities (that is they may not be a coach in the future, then you have to create a whole new object). From that it seems logical that these people have some attribute that makes them a coach.
Jason Tholstrup
continued... So from there we have a couple of options: 1) make new objects that contain a person like Steven A. Lowe mentions or 2) make new role/ability/responsibility objects that are attributes of the person. The second seemed to mimic reality a bit more closely so I went with that one.
Jason Tholstrup
+3  A: 

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);
Steven A. Lowe