OO设计和循环依赖 [英] OO design and circular dependencies

问题描述

在设计类时，我目前正在努力解决循环依赖问题.

I am currently struggling with a circular dependency problem when designing my classes.

自从我阅读 Anemic Domain Model (我一直在做的事情)以来，我一直试图摆脱创建仅仅是"getter和setter的存储桶"的域对象，并返回到我的OO根目录.

Ever since I read about the Anemic Domain Model (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.

但是，下面的问题是我遇到的很多问题，我不确定应该如何解决.

However, the problem below is one that I come across a lot and I'm not sure how I should solve it.

假设我们有一个团队类，其中有许多播放器.这是什么运动都没有关系:)球队可以添加和删除球员，就像球员离开球队并加入另一个球队一样.

Say we have a Team class, that has many Players. 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.

所以我们有一个团队，其中有一个球员名单:

So we have the team, which has a list of players:

public class Team {

    private List<Player> players;

    // snip.

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

然后我们有了玩家，它引用了团队:

Then we have the Player, which has a reference to the Team:

public class Player {
    private Team team;

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

可以假设这两种方法(删除和离开)都具有特定于域的逻辑，每当团队删除一名球员且一名球员离开球队时都需要运行该逻辑.因此，我首先想到的是，当 Team 踢出球员时，removePlayer(...)还应该调用player.leaveTeam()方法...

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 Team kicks a player, removePlayer(...) should also call the player.leaveTeam() method...

但是，如果 Player 促使出发，该怎么办-LeaveTeam()方法应该调用team.removePlayer(this)吗?并非没有无限循环！

But then what if the Player is driving the departure - should the leaveTeam() method call team.removePlayer(this)? Not without creating an infinite loop!

过去，我只是将这些对象设置为哑" POJO，并让服务层来完成工作.但是即使到现在，我仍然面临着这个问题:为了避免循环依赖，服务层仍将所有链接都链接在一起-即

In the past, 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.

public class SomeService {

    public void leave(Player player, Team team) {

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

    }

}

我是否使这个复杂化了?也许我缺少一些明显的设计缺陷.任何反馈将不胜感激.

Am I over complicating this? Perhaps I'm missing some obvious design flaw. Any feedback would be greatly appreciated.

谢谢大家的答复.我接受 Grodriguez 的解决方案，因为它是最显而易见的(不相信这不是我想到的)并且易于实现.但是， DecaniBass 确实很不错.在我所描述的情况下，玩家可能会离开团队(并意识到他是否在团队中)以及推动移除的团队.但是，我同意你的观点，并且我不赞成在此过程中有两个入口点"的想法.再次感谢.

Thanks all for the responses. I'm accepting Grodriguez's solution as it is the most obvious (can't believe it didn't occur to me) and easy to implement. However, DecaniBass 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.

推荐答案

您可以通过添加警卫人员来检查团队是否仍然有该球员/该球员仍在团队中，从而打破循环依赖.例如:

You can break the circular dependency by adding guards to check if the team still has the player / the player is still in the team. For example:

在Team类中:

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

在Player类中:

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

这篇关于OO设计和循环依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！