隐式数据结构与显式数据结构

Question

最近我一直在为一些反复出现的设计问题而苦苦挣扎，我不知道如何优雅地解决这些问题。

假设我正在制作一个有几个玩家的游戏，每个玩家都有一些相连的棋子。这些部分组合在一起形成了一个半复杂的集合或结构。现在我可以用两种方式来实现这个结构:或者通过指针在片段本身中隐式地存储结构，即：

class BigPiece extends Piece {
    Piece opposingPiece, nextPiece, previousPiece, index;
}

或者我可以在一个集合类中实现这个结构，并保持信息的集中化：

class SomeCollection<Collection<Piece>> {
    SomeOtherCollection<Collection<Piece>> collection 
        = new SomeOtherCollection<Collection<Piece>>();

    public SomeCollection() {
        collection.add(new PieceCollection<Piece>();
        collection.add(new PieceCollection<Piece>();
        collection.add(new PieceCollection<Piece>();
    }

    public Piece getPiece(int playerIndex, int pieceIndex) {
        collection.get(playerIndex).get(pieceIndex);
    }

    public Piece getOpposingPiece(int playerIndex, int pieceIndex) {
        int nextPlayerIndex = collection.listIterator(playerIndex).nextIndex();
        return this.collection.get(nextPlayerIndex).get(pieceIndex);
    }
}

现在我通常倾向于第二个，但这只是基于我的直觉，我在类设计方面没有太多经验，特别是在大型应用程序方面。我可以看到正反两方面的意见。

对于第一个解决方案，我通常遇到的问题是，您仍然需要在一些构建器或工厂中创建关联，这些关联实际上将对象链接在一起。这对我来说似乎不是很健壮。谁能向我保证，在应用程序的整个生命周期中，所有的指针都是正确的？

第二种解决方案更集中了数据。但这确实降低了更高的类(比如单个块)。我通常遇到的问题是，每当我想遍历这个集合时，我都必须在较低的级别上进行。你不能问一段‘嘿，你的对立面是什么？’不，你必须获得一个游戏对象来获得一个指向你的集合的指针，然后你就会问对方的棋子是什么。这使得更多的“管理”类从你的应用程序周围收集数据(method chaining =( ))，最终实现你的算法。这似乎违反了Law of Demeter。

当然，我也可以从每个单独的片段中添加一个指向相应集合的指针，但我不知道这是不是一个好主意，因为这似乎只是重复的信息。

Answer 1

我个人的建议是更多的第二种选择，而不是第一种。正如你所指出的，一块不应该(至少在这个上下文中)知道它的对立面/下一块/上一块是什么。

管理器类更有逻辑意义，可以更好地促进类之间的通信，而不是引用其他部分的块。我承认我不完全了解德米特定律，但Wikipedia让我相信这一切都是关于封装的，而管理器类实际上也会有所帮助！

我不认为块(在这种情况下)应该能够，比方说，移动另一块。然而，manager类在逻辑上会希望这样做。

这就是我的建议，我希望它能有所帮助！