title: OO design and circular dependencies
body: <p>I am currently struggling with a circular dependency problem when designing my classes. </p>
  
  <p>Ever since I read about the <a href="http://martinfowler.com/bliki/AnemicDomainModel.html">Anemic Domain Model</a> (something I was doing all the time), I have really been trying to get away from creating domain objects that were just "buckets of getters and setters" and return to my OO roots.</p>
  
  <p>However, the problem below is one that I come across a lot and I'm not sure how I should solve it.</p>
  
  <p>Say we have a <strong>Team</strong> class, that has many <strong>Players</strong>. It doesn't matter what sport this is :) A team can add and remove players, in much the same way a player can leave a team and join another.</p>
  
  <p>So we have the team, which has a list of players:</p>
  
  <pre><code>public class Team {
  
      private List&lt;Player&gt; players;
  
      // snip.
  
      public void removePlayer(Player player) {
          players.remove(player);
          // Do other admin work when a player leaves
      }
  }
  </code></pre>
  
  <p>Then we have the Player, which has a reference to the Team:</p>
  
  <pre><code>public class Player {
      private Team team;
  
      public void leaveTeam() {
          team = null;
          // Do some more player stuff...
      }
  }
  </code></pre>
  
  <p>One can assume that both methods (remove and leave) have domain-specific logic that needs to be run whenever a team removes a player and a player leaves a team. Therefore, my first thought is that when a <strong>Team</strong> kicks a player, removePlayer(...) should also call the player.leaveTeam() method... </p>
  
  <p>But then what if the <strong>Player</strong> is driving the departure - should the leaveTeam() method call team.removePlayer(this)? Not without creating an infinite loop!</p>
  
  <p><strong>In the past</strong>, I'd have just made these objects "dumb" POJOs and had a service layer do the work. But even now I'm still left with that problem: to avoid circular dependencies, the service layer still has link it all together - i.e.</p>
  
  <pre><code>public class SomeService {
  
      public void leave(Player player, Team team) {
  
          team.removePlayer(player);
          player.leaveTeam();
  
      }
  
  }
  </code></pre>
  
  <p>Am I over complicating this? Perhaps I'm missing some obvious design flaw. Any feedback would be greatly appreciated.</p>
  
  <hr/>
  
  <p>Thanks all for the responses. I'm accepting <strong>Grodriguez</strong>'s solution as it is the most obvious (can't believe it didn't occur to me) and easy to implement. However, <strong>DecaniBass</strong> does make a good point. In the situation I was describing, it is possible for a player to leave a team (and be aware of whether he is in a team or not) as well as the team driving the removal. But I agree with your point and I don't like the idea that there's two "entry points" into this process. Thanks again.</p>