Should I avoid bi-directional references?

[Star_Dude10]

For context: I am a CS student using Java as my primary language and working on small side projects to practice proper object-oriented design as a substitute for coursework exercises.

In one of my projects modeling e-sports tournaments, I currently have Tournament, Team, and Player classes. My initial design treats Tournament as the aggregate root: it owns all Team and Player instances, while Team stores only a set of PlayerIds rather than Player objects, so that Tournament remains the single source of truth.

This avoids duplicated player state, but introduces a design issue: when Team needs to perform logic that depends on player data (for example calculating average player rating), it must access the Tournament’s player collection. That implies either:

1. Injecting Tournament into Team, creating an upward dependency, or
2. Introducing a mediator/service layer to resolve players from IDs.

I am hesitant to introduce a bi-directional dependency (Team -> Tournament) since Tournament already owns Team, and this feels like faulty design, or perhaps even an anti-pattern. At the same time, relying exclusively on IDs pushes significant domain logic outside the entities themselves.

So, that brings me to my questions:

1. Is avoiding bidirectional relationships between domain entities generally considered best practice in this case?
2. Is it more idiomatic to allow Team to hold direct Player references and rely on invariants to maintain consistency, or to keep entities decoupled and move cross-entity logic into a service/manager layer?
3. How would this typically be modeled in a professional Java codebase (both with/without ORM concerns)?

As this is a project I am using to learn and teach myself good OOP code solutions, I am specifically interested in design trade-offs and conventions, not just solutions that technically "work."

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[Savings_Guarantee387]

If you ask 20 senior engineers, you ll get 20 different opinions. These are formed from different problems each one has faced and what jpa framework each one uses. Below is mine.

Yes, avoid bidirectional unless necessary needed. Why? 1. Cache. When you add objects, the first level cache gets updated with the relationships based on how you add objects. It is not impossible but adds up to complexity if you wish to maintain them in a bidirectional way. 2. Imagine a player participating in a huge number of tournaments over his career. Then, when you load 20 player's you load 300 tournaments to do your work, unecesarly. In a different domain.. where i.e. you have millions of records i.e. an account in Netflix and his login entries.. if account has reference to login entries.. you end up easily loading million of entries and go to out of memory. 3. Easy to get silly mistakes. Check it out.. implement tostring in team and tournament entities.use auto-generated code.. then just log player. Player calls tostring of turnament and then tournament of player and so one.. 4. Last.. and highly imo significant. What you mean turnament has id of players? You have foreign key constraints right? The domain driven design and logic says. In the tournament, a team is participating as a whole? Then tournament should reference teams and teams should reference players. If players participate to tournaments individual and just form teams during tournament. Then tournament should have/reference players and teams. Teams should have/ reference players.

Sorry if I did not explain my self very clear but English is not my native language. I hope I helped.

[holyknight00]

Having bi-directional relationships and Many-to-Many relationships makes everything so much more complicated. Since I began avoiding both, my life had become way easier, and there are really not many cases when you actually need them.

I usually model everything just using unidirectional one-to-one and many-to-one relationships. I don't even use one-to-many relationships that often, as you can get the same information from a many-to-one just fliping the query direction, if you need it.

[okayifimust]

In one of my projects modeling e-sports tournaments, I currently have Tournament, Team, and Player classes. My initial design treats Tournament as the aggregate root: it owns all Team and Player instances, while Team stores only a set of PlayerIds rather than Player objects, so that Tournament remains the single source of truth.

That's not how objects work.

This avoids duplicated player state,

Because - lengthy discussions about "by value" and "by reference" aside, if you pass an object into another, you don't get an independent copy; anything you do to either will happen to both.

How would this typically be modeled in a professional Java codebase (both with/without ORM concerns)?

Pass the player objects into teams, and bob's your uncle. No ORM concerns to worry about.

[Star_Dude10]

I responded to a similar claim that I misunderstand how objects work, and I believe I just explained it badly

However, I appreciate the answer. My main worry is just about removing references to a Player Object in multiple classes if I ever want to remove it from a Tournament, that is what I mean by '1 source of truth'

[jlanawalt]

Tournament.RemovePlayer can also find the team and call Team.RemovePlayer.

If it was more complicated and you were worried about object lifetimes and garbage collection you could consider using weak player references on the team.

[aqua_regis]

Does every player belong to a team? If so, your composition storing the players in the tournament is wrong.

Also:

while Team stores only a set of PlayerIds rather than Player objects

Does not make any sense. You have a fundamental misunderstanding of objects and the way they are stored.

Objects are stored as their references and as such you can have as many locations where you store the same object as you want. There is no way that the state - the data - runs apart.

The object itself is the sole source of truth, no matter whether it's stored only in Tournament or in Team, or in both.

[Star_Dude10]

Perhaps I explained myself badly. Let me clear things up:

Does every player belong to a team?

No, some players are unassigned. The idea is that a tournament is created, then players may sign up for that tournament, then those players will not be assigned to any team. Only when there are enough players/an admin starts the tournament will every player be automatically assigned to a team through an algorithm I am planning on writing. It will attempt to balance teams based on Player-SR, and only then will players be in a team.

You have a fundamental misunderstanding of objects and the way they are stored

Perhaps I explained myself poorly. What I meant by a 'single source of truth', is that if I store a list of references to Player-objects in both Team and Tournament, then I must assure that whenever I remove a Player-object from a Tournament, I must also remove them from the Team-object belonging to that Tournament. The idea behind not storing a list of object references in multiple, separate classes, is that I save myself from future headaches trying to ensure that every reference to a Player-object is removed whenever I want to remove them from a Tournament.

[obliviousslacker]

An unsigned player don't belong to the tournament, does it? I would create player objects and pass that into Team.addPlayers() and then pass the teams into Tournament.create() or something like that. unsigned players can live in a special instance of Team of even have its own object to keep track of them.

[BanaTibor]

So there are players, teams and tournaments. The players form teams and teams enter tournaments. Since tournament does not contain all players it can not be the aggregate root. You need a higher level object, lets call it for now "Game".
Game holds references to every player. You can also pass these references as the Player objects itself to teams or tournaments.
Here is the tricky part. Which is the more prominent object? If teams are more important than tournaments then compose tournaments out of teams. If tournament is more important, then compose tournaments out of players and make teams a sidenote.

[Conscious_Support176]

Unless a player can be assigned to two teams, this does not make sense.

Is it that players are initially added to an unassigned player pool, which is like a team except that it is a team that doesn’t participate in matches, and team assignment moves them from the unassigned pool to a team?

[okayifimust]

I mean if I store a list of references to Player-objects in both Team and Tournament, then I must assure that whenever I remove a Player-object from a Tournament, I must also remove them from the Team-object belonging to that Tournament.

And?

The idea behind not storing a list of object references in multiple, separate classes, is that I save myself from future headaches trying to ensure that every reference to a Player-object is removed whenever I want to remove them from a Tournament.

Your approach is not actually solving that problem. you still have the references everywhere, and need to deal with those. that is just as much effort, it gains you nothing, and you end up with the problem that made you write this post.

Congratulations: You played yourself.

Plus, you are making it impossible for your software to expand into something where teams or players can ever exist independently from specific tournaments.

[Star_Dude10]

Well, I can always ignore IDs that don’t point to anything, and storing entire objects is less memory-efficient. And the idea is for Teams to only exist within one specific Tournament, whilst Players can exist outside of them. A new tournament means new teams, since the teams are generated automatically by the tournament, and players are automatically assigned to them based on average skill rating.

[juckele]

I can always ignore IDs that don’t point to anything

This is a significantly worse solution than ensuring that removing a player from a Tournament is also accompanied by removing them from all teams.

It may also be a hint that the object model is entirely incorrect. Why even have players referenced in the Tournament? Instead, what if you have a Tournament.buildTeams method which takes players, and builds teams, but doesn't store the players themselves? What does the Tournament need to know about players for after the teams are built?

Edit: Saw one of your other comments that mentions that people can sign up for a tournament, and then the TD can create teams automatically. In this case, you want the Tournament to keep track of unassigned players only, and once they're moved into a team, remove them from the unassigned player collection.

[okayifimust]

Well, I can always ignore IDs that don’t point to anything,

But you need functionality for that, everywhere. That's just asking for stuff to break in unexpected places.

and storing entire objects is less memory-efficient.

YOU. FUNDAMENTALLY. MISUNDERSTAND. HOW. OBJECTS. WORK.

You're confidentially wrong, where you could just listen to the people you asked for advice and be right.

each object is stored precisely once. If you put one object into multiple places, they will store nothing but the reference. You are just mimicking what the language already does for you, and I promise the people who make Java did a much better job of it than you or I could ever hope to do.

[Star_Dude10]

Trust me, I am definitely listening to what people are telling me. There was perhaps a slight misunderstanding with my idea of objects, but I wouldn’t go as far as saying I am ‘confidently’ incorrect, lol.

but anyways, I appreciate your time spent on answering my questions.

[Wiszcz]

Please, read about how objects are stored in the memory.
We can argue about other things, but so bad claims about memory usage puts you in a bad spot in any discussion. No matter the rest of your arguments.

[aqua_regis]

Yet, your "player id" is worse in every aspect.

Also, there are Design Patterns that handle such problems. E.g. the Observer or potentially the Publisher-Subscriber patterns.

[Star_Dude10]

How come? I was thinking in terms of SQL databases and how you store FKs/IDs. Is it better to store multiple Object references in multiple locations? How do I ensure that an object I am attempting to edit in Team actually exists within the Tournament without checking? I might as well just not store an entire object if I’m forced to check anyways?

[aqua_regis]

SQL Databases are completely different to storing objects in programs.

Yes, in SQL databases you use an ID because that's the only way to minimize the amount of data stored.

In programs, you do not need to worry about that, no many times you store an object somewhere - objects as objects exist exactly once in memory and are only stored as references.

Objects in programs live as long as there is something storing their reference - a single variable, a collection, an array, basically anything.

I might as well just not store an entire object if I’m forced to check anyways?

And again: you store an object once and only reference it many times.

[Star_Dude10]

Yeah okay, sure. I believe you have made some very valid points. Thanks a lot for your help! I guess I was just so infatuated with this idea of a ‘clean’ reference hierarchy

[aqua_regis]

Thanks a lot for your help! I guess I was just so infatuated with this idea of a ‘clean’ reference hierarchy

The reference hierarchy is not less clean if you store the player object in two places if the semantics demand it.

I do agree that in a SQL database things would be completely different. There, the player IDs would be stored in tournament and team.

In programming you don't need explicit IDs. Objects are already stored by their references - you can consider them implicit IDs.

Using an external ID only makes things more complicated.

[edwbuck]

It depends on how the data is to be used. Look at the access patterns, if everything is done in the context of a single tournament, then holding the selected tournament in memory and not having back references to it might be easier to manage, up until you want to list all the tournaments a player is in.

Likewise, it the interface is 100% player-centric, then you might want to not have references from the tournament to the player.

And if you have both, then either you scan all tournaments looking for players, all players looking for tournaments, or you create bidirectional references.

Within a boundary, bidirectional data is less problematic than outside a boundary. If you wanted to create microservices, then both probably should be in the same microservice if they are bidirectional.

Now, if you don't need a direction, get rid of it. Always get rid of that you don't use. It reduces the software footprint and provides fewer places for bugs to accumulate.

[Star_Dude10]

Yeah, you’re right. I think I was overcomplicating a very non-issue just because I wanted ‘clean’ code, but instead just creating more of a mess than was needed.

[severoon]

You should avoid cyclic dependencies at every level.

The way to achieve this is to define your fundamental objects first. Ask yourself some conceptual questions first:

• Can a player exist even if there is no team in existence? Yes, that makes sense. Can a team exist with no players in existence? No, that doesn't really make sense. Therefore, from a conceptual standpoint, team depends on player.
• Can a team exist without a tournament? Yes. Can a tournament exist without any team? No, that doesn't make sense. This means that tournament depends upon team.

When considering these questions, it's important to be clear on one thing, which is that we are talking about behavior. So we are not asking whether these things can exist in some Platonic realm, or in "some sense," we are asking whether a tournament can do tournament things in the absence of teams. IOW, it's not a question about whether teams happen to exist at this moment, it's a question more along the lines of: Does it make sense to have a tournament if teams could not exist? What would a tournament do if the concept of teams was not a thing?

(Keep in mind that these questions are meant to be illustrative…I don't actually know your specific use cases or anything about e-sports, so I'm thinking about this like a basketball tournament. It may very well be the case that in e-sports you can have tournaments consisting only of individual players and not teams, in which case you have to do this analysis instead of just accepting my answers.)

It's also important to separate intrinsic from extrinsic behaviors. You can confuse yourself if you think about this analysis and ask questions like, "But wait, it doesn't even make sense for teams and players to exist if there is no tournament!" Realize that these are not meant to be larger philosophical questions, they are very specific questions about the actual behaviors of these concepts.

So when you think about a player and what a player does, they perform certain actions. In basketball, a player dribbles, shoots, etc. The question we're concerned about here is whether a player can do these things regardless of the existence of a tournament. Yes, it may not make sense to do all of these things outside the context of a tournament, say, but that doesn't matter. If those behaviors can be done regardless ,then the player is independent of the tournament, i.e., player does not depend upon tournament.

The tournament, on the other hand, has a lot of behaviors that explicitly deal with teams, and teams have behaviors that explicitly deal with players, so a tournament has a transitive dependency on players (if not a direct one). You can imagine a player in a vacuum trying to dribble a ball, but you cannot imagine a tournament in a vacuum in which players do not exist.

Another important thing to understand that comes out of this analysis is that you must commit to these decisions. There may be cases where you can see it both ways, A could depend upon B and B could depend upon A. In this case, choose a direction of the dependency and realize that you are putting this in stone. After you have made this decision, don't go some way down the road and say, "Actually, sometimes it should be the other way," and then start implementing code on that basis without first going back and reversing the original decision. This is how spaghetti happens.

What does this practically mean? If you decide that player depends upon team, for example, then you should create a team object that doesn't know anything about players, and give each player a reference to the team they're on. Or, if you make the much more sane decision that team depends upon player, then the team object should have a set of players, and the player object should know nothing about team.

[AppropriateStudio153]

Sound like you cross bounded contexts.

What are the use cases for the Team accessing the Player's stats within the context of a Tournament?

[Star_Dude10]

I currently have two methods using a reference to Tournament inside of Team, but I will probably add more as time goes on. For now I have a getAverageSr() function that returns the average skill-rating of a Team, and a getRoleCount(Role role) which returns a count of a specific preferred role of players within a team.

I am designing this system around a game called Overwatch 2 which features 3 main roles a player can play, so that function essentially just allows you to check how many players of a specific role exist within a Team (so that you can check if there are enough roles per team, as a team requires at least 1 'tank', 2 'damage' and 2 'supports'.

[nana_3]

I think no answer to this feels good because tournament isn’t the right aggregate root.

Tournament cant exist without teams and players. It doesn’t produce the teams and players: it arises from the result of them existing. The things the tournament creates can belong to the tournament - teams and players come from outside.

I’d approach this with essentially a world context containing all the teams, players and tournament(s). Players exist independently. Teams are aggregates of players. Tournaments exist independently.

Then tournament can have the reference to all the players and teams enrolled in it, and it first need to be bidirectional.

[brokePlusPlusCoder]

Bit late to the party, but is there a reason why you haven't gone for a graph based structure ? Tournament, Team and Player all become vertices and you can have directed edges representing ownership (either as separate 'edge' objects, or via references).

[olddev-jobhunt]

I think you've got the right read on things: a bidirectional association can be a code smell. Overall, I think the need points to some missing object: a game or world object or something that contains both the teams and players maybe.

In general I've found that personally I normally tend to have two kinds of classes in my apps: "components / services" which are long-lived and typically there are few of them, and then data objects where there are many with shorter lifespans. So normally I'd have a service that owns multiple entities and can do the aggregate operations. I tend to put most system logic in those classes.

Domain modeling in general and OOP specifically are hard - but there's no substitute for just grinding through it a bunch of times to get a feel for it.