Will this usage of List<T> be a miracle or a mess

I want to dispatch appointments to reps (I spare you the details).

I need to have, for each rep, a list of the appointments he cas do. I also need, for the second step, a lis开发者_运维问答t of the possible reps for each appointment.

I want to compile my data only once. What if I have something like this:

class Rep
{
    int repNumber;
    List<Appointment> availableApps;
}

class Appointment
{
    int appointmentNumber;
    List<Rep> availableReps;
}

Am I running after trouble? It seems fine to me, but I see it possibly creates a kind of infinite reference circle.

What do you think? Thank you

---

It's all fine; classes are reference types.

---

I don't see anything wrong with this. You see similar classes in the .NET Framework like forms and controls, for example:

myControl.childControl.Parent

myControl can refer to children controls, which can then refer back to it's parent.

---

It looks like your typical many-to-many relationship.

Just make sure you have proper logic in there. If a rep gets fired, what happens to his appointments? Like all complex structures, there's lots of gotchyas that can trip you up.

---

It's alright. Double-linked list has "infinite reference circle" too, so what. It's one way to design many-to-many relationships.

Keep that in mind if you ever want to serialize the data though. Some serializers don't handle this kind of stuff well. The same goes with custom implementations of IEquatable and overriding GetHashCode: there are ways to screw something up in these operations when your data structure is like that.

Basically, you're fine unless you want to implement some deep (rather than shallow) operations like cloning, comparing, serializing and so on. Then you have to be careful.

---

It is perfectly valid; C# (and most other languages) handles types that reference each other in a circular manner. The reason it does not cause problems is that all variables of class type are references. So a Rep object wouldn't contain many Appointment objects; rather, it references a list which again contains references many Appointment objects. Each Appointment object references a list which contains references to many Rep objects (which might well be the same Rep objects that referenced the Appointment objects).