views:

158

answers:

7

what is best way to model many-to-many relationship?

lets say we have a two classes , Team and Player

  • any given Player can be in multiple Team s
  • any Team can have as many Player s as they like

I like to call methods like

  • playerX.getTeamList() to get the list of all the Team s he/she is in
  • teamY.getPlayerList() to get the list of all the Player s in the team

(or have some other way to do this effectively)

I can think of two ways of doing this , but they just don't feels like good oop pattens. can you think of any good ways , perhaps a design patten ?

+2  A: 

it is fine, Player has a collection of Team and Team has collection of Player. You need to be careful about integrity in add/remove operations, because they are not "atomic"

Andrey
+2  A: 
public class Player
{
  public Team[] Teams {get;set;}
}

public class Team
{
  public Player[] Players {get;set;}
}

Perfectly reasonable.

Will
You're overlooking the real issue, which is the need to keep their contents in sync. One way to guarantee this is to implement one in terms of the other.
reinierpost
@rein Who says that's the "real issue"? We can't tell what any issue is unless we know how his application is written. He didn't specify if they are models (logicless drones stuffed with data and sent on their way) or entities (classes which have rich frameworks that support lazy loading and other storage paradigms) or something else. The simplest model is for these types to be instantiated by a repository or a storage layer of some sort which is responsible for all operations which affect teams and players.
Will
KISS, until you can't.
Will
+1  A: 

It's worth to distinguish the API feel from actual implementation.

While it makes sense for both classes to expose such a collection (e.g. get*List()), they don't neccessarily have to hold the instance of the collection.

I suggest you create a League class or something alike, that holds some sort of a private player-team mappings dictionary. Additions to those 'collections' thorough the Team/Player instance, should call internal methods on the League instance to update the mappings. This way, you keep updates atomic (as Andrey suggested) and error free.

Yaakov Davis
A: 

IMHO what you describe is the "natural" way for OO. Your XXX.getXXXList() is the interface to your classes. And for a limit number of classes that would be the right way.

Consider there are 1000 classes that can be "interconnected". Than it may be interesting to have some ManyToManyManager to drop in an object, add another object to the related objects of an object and retrieve the list of all objects releated to another. That would be some sort of delegation vs. implementation.

Shure if you delegate your many-to-many to another instance your object model do not reflect that many-to-many relation anymore.

PeterMmm
+1  A: 

The answer from Will is correct. However, to deal with syncing, I would probably start with ObservableCollection. Have one side of the relationship be the "master" which keeps track of adds / removes on the other side and deals with syncing.

However, be aware that if one object is subscribing to events on the other that this is a strong reference that will prevent garbage collection. Most likely they will be leaving scope at the same time so this is a non-issue but it is something to be aware of.

jkohlhepp
Hmm... where have we seen this problem before :)
LBushkin
+2  A: 

Relationship between players and teams form Bipartite Graph. Expecting comments(and downvotes?)! I am OOD noob.

    class MyPlayer
    {
        public string Name { get; set; }

        public MyPlayer(string n)
        {
            Name = n;
        }
    }

    class MyTeam
    {
        public string Name { get; set; }

        public MyTeam(string n)
        {
            Name = n;
        }
    }

    class PlayerTeamPair
    {
        public MyPlayer Player { get; set; }
        public MyTeam Team { get; set; }

        public PlayerTeamPair(MyPlayer p,MyTeam t)
        {
            Player = p;
            Team  = t;
        }
    }

    class PlayerTeamBipartiteGraph
    {
        public List<PlayerTeamPair> Edges { get; set; }

        public PlayerTeamBipartiteGraph()
        {
            Edges = new List<PlayerTeamPair>();
        }

        public void AddPlayerAndTeam(MyPlayer p, MyTeam t)
        {
            Edges.Add(new PlayerTeamPair(p, t));
        }

        public List<MyTeam> GetTeamList(MyPlayer p)
        {
            var teams = from e in Edges where e.Player == p select e.Team;
            return teams.ToList<MyTeam>();
        }

        public List<MyPlayer> GetPlayerList(MyTeam t)
        {
            var players = from e in Edges where e.Team == t select e.Player;
            return players.ToList<MyPlayer>();
        }

    }


    class Program
    {
        static void Main(string[] args)
        {
            var G = new PlayerTeamBipartiteGraph();

            MyPlayer a = new MyPlayer("A");
            MyPlayer b = new MyPlayer("B");
            MyPlayer c = new MyPlayer("C");
            MyPlayer d = new MyPlayer("D");

            MyTeam t1 = new MyTeam("T1");
            MyTeam t2 = new MyTeam("T2");

            G.AddPlayerAndTeam(a, t1);
            G.AddPlayerAndTeam(b, t1);
            G.AddPlayerAndTeam(c, t1);
            G.AddPlayerAndTeam(b, t2);
            G.AddPlayerAndTeam(d, t2);

            G.GetTeamList(b).ForEach(t => Console.Write(" {0} ",t.Name));
            Console.WriteLine();
            G.GetPlayerList(t2).ForEach(p => Console.Write(" {0} ",p.Name));
            Console.WriteLine();
        }
    }
TheMachineCharmer
A: 

Split the many-to-many relationship into two one-to-many's. Makes everything a lot more simple.

Lotus Notes