2011-07-28 5 views
1

Dernièrement, j'ai eu des problèmes de conception récurrents que je ne sais pas résoudre avec élégance. Dites que je fais un jeu avec un couple de joueurs et pour chaque joueur des pièces connectées. Ensemble, ces pièces forment une collection ou une structure semi-complexe. Maintenant, je pourrais mettre en œuvre cette structure de 2 façons: Soit stocker la structure implicitement par des pointeurs dans les pièces elles-mêmes à savoir:Structures de données implicites et explicites

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

Ou je pourrais mettre en œuvre cette structure dans une classe de collecte et de garder les informations centralisées:

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

Maintenant, je préfère habituellement le second, mais c'est juste basé sur mes tripes et je n'ai pas beaucoup d'expérience en conception de classe, surtout pas avec de grandes applications. Je peux voir les avantages et les inconvénients des deux côtés.

Le problème que j'ai habituellement avec la première solution est que vous devez encore créer les associations dans un constructeur ou une usine qui relie réellement les objets ensemble. Cela ne me semble pas très robuste. Qui peut me rassurer que tous les pointeurs sont réellement corrects tout au long de la vie de l'application?

La deuxième solution centralise davantage les données. Cela abaisse vraiment les classes supérieures (comme les pièces individuelles). Le problème que j'ai habituellement avec ceci est que chaque fois que je veux traverser cette collection, je dois le faire à un niveau inférieur. Vous ne pouvez pas demander un morceau 'Hey, quelle est votre pièce opposée?'. Non, vous devez obtenir un objet de jeu pour obtenir un pointeur sur votre collection, puis vous demandez quel est le morceau adverse. Cela rend plus de classes de 'managery' qui collectent des données de tout autour de votre application (méthode chaining =() pour finalement implémenter votre algorithme.) Law of Demeter

Bien sûr, je pourrais ajouter un pointeur à la collection correspondante de chaque pièce individuelle aussi, mais je ne sais pas si c'est une bonne idée, car cela ne semble être que des informations en double

Répondre

0

Ma recommandation personnelle est plus la seconde option par opposition à la première. La pièce ne devrait pas (au moins dans ce contexte) savoir quelle est sa pièce opposée/suivante/précédente

Une classe de gestionnaire serait logique de mieux faciliter la communication entre les classes au lieu de morceaux ayant des références à d'autres pièces. J'avoue que je ne connais pas parfaitement la loi de Demeter mais Wikipedia m'amène à croire que c'est une question d'encapsulation que les classes de managers aideraient aussi!

Je ne pense pas que Pieces (encore une fois, dans ce contexte) devrait pouvoir, disons, déplacer un autre morceau. Cependant, une classe de gestionnaires le voudrait logiquement.

C'est ma suggestion, j'espère que ça aide!

Questions connexes