Atualmente, estou enfrentando um problema de dependência circular ao projetar minhas classes.

Desde que li sobre oModelo de domínio anêmico (algo que eu fazia o tempo todo), eu realmente estava tentando evitar criar objetos de domínio que eram apenas "baldes de getters e setters" e retornar às minhas raízes OO.

No entanto, o problema abaixo é um que me deparo bastante e não tenho certeza de como devo resolvê-lo.

Digamos que temos umEquipe classe, que tem muitosJogadoras. Não importa que esporte seja esse :) Um time pode adicionar e remover jogadores, da mesma maneira que um jogador pode deixar um time e se juntar a outro.

Então, temos a equipe, que tem uma lista de jogadores:

public class Team {

    private List<Player> players;

    // snip.

    public void removePlayer(Player player) {
        players.remove(player);
        // Do other admin work when a player leaves
    }
}

Depois, temos o jogador, que tem uma referência à equipe:

public class Player {
    private Team team;

    public void leaveTeam() {
        team = null;
        // Do some more player stuff...
    }
}

Pode-se supor que ambos os métodos (remover e sair) têm uma lógica específica do domínio que precisa ser executada sempre que um time remove um jogador e um jogador sai de um time. Portanto, meu primeiro pensamento é que quando umEquipe chute um jogador, removePlayer (...) também deve chamar o método player.leaveTeam () ...

Mas e se oJogador está conduzindo a partida - o método leaveTeam () deve chamar team.removePlayer (this)? Não sem criar um loop infinito!

No passado, Eu teria acabado de tornar esses objetos "burros" POJOs e teria uma camada de serviço para fazer o trabalho. Mas mesmo agora ainda me resta esse problema: para evitar dependências circulares, a camada de serviço ainda vincula tudo - ou seja,

public class SomeService {

    public void leave(Player player, Team team) {

        team.removePlayer(player);
        player.leaveTeam();

    }

}

Estou mais complicando isso? Talvez eu esteja perdendo alguma falha de design óbvia. Qualquer comentário seria muito apreciado.

Obrigado a todos pelas respostas. Estou aceitandoGrodriguezA solução, pois é a mais óbvia (não posso acreditar que isso não tenha me ocorrido) e fácil de implementar. Contudo,DecaniBass faz um bom argumento. Na situação que descrevi, é possível que um jogador saia de um time (e saiba se ele está em um time ou não), assim como o time que está conduzindo a remoção. Mas eu concordo com o seu ponto de vista e não gosto da ideia de que haja dois "pontos de entrada" nesse processo. Obrigado novamente.