隱式與顯式數據結構

最近我一直在努力解決一些經常性的設計問題，我不知道如何優雅地解決問題。隱式與顯式數據結構

說我做一個遊戲與一對夫婦的球員，每個球員的一些連接件。這些部分一起形成一個半複雜的集合或結構。現在，我可以通過兩種方式實現此結構：要麼通過在片指針隱式存儲本身的結構，即：

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); 
    } 
}

現在我通常喜歡第二個，但這只是基於我的膽量，我沒有那麼多的課堂設計經驗，特別是沒有大的應用程序。我可以看到雙方的利弊。

的問題，我通常與第一個解決方案是，你仍然必須建立在一些製造商或工廠實際上物體連接在一起的關聯。這對我來說似乎不太健壯。誰能讓我放心，在應用程序的整個生命週期中，所有的指針都是正確的？

第二個解決方案更集中了數據。儘管如此，這確實會讓更高等級的學生感到沮喪（比如單個的片段）。我通常遇到的問題是每當我想要遍歷這個集合時，我都必須在較低的層次上進行。你不能問一件'嘿，你的對手是什麼？'。不，你必須得到一個遊戲對象來獲得一個指向你的集合的指針，然後你會問這個對手是什麼。這使得更多的'管理'類從你的應用程序收集數據（方法鏈=（），以最終實現你的算法。這似乎違反了Law of Demeter。

當然，我可以添加一個指針，單件爲好，但我不知道這是個好主意，因爲這只是似乎是重複的信息。

來源

2011-07-28 Vja

我個人的建議是moreso，而不是第一個。正如你指出的那樣，第二個選項一塊不應該（在這種情況下至少）知道其相對/下一首/上一塊是什麼。

Manager類會更有邏輯意義，更好地促進類之間的通信，而不是引用其他作品的作品。我承認我並不完全瞭解得墨忒耳定律，但Wikipedia讓我相信這是關於經理類真正幫助的封裝。

我不認爲飲片（再次，在這種情況下）應該可以，比方說，將另一塊。然而，一個經理階層在邏輯上會想要。

這是我的建議，我希望它有幫助！

來源

2011-07-28 18:53:22 KennyRules

隱式與顯式數據結構

回答

相關問題