(Remarque: cela plus d'une question théorique) p>
Salut! J'ai créé un jeu de société de travail appelé Checkers, qui est un peu comme des échecs, sauf qu'il y a des pièces et des règles différentes, et je l'ai fait sans utiliser d'interfaces. Cependant, j'ai remarqué que cela a dit dans nos instructions d'affectation à domicile selon lesquelles au moins une interface doit être utilisée. p>
Donc, je me demande quand est-il approprié d'utiliser une interface en Java ou plus précisément lorsque cela peut-il être bénéfique dans un jeu de société comme des dames ou des échecs pour utiliser une interface? J'essaie de comprendre ce que je pouvais éventuellement créer une interface pour (comme les mouvements, dessiner à la planche, etc.), cela bénéficierait probablement au programme. P>
3 Réponses :
Généralement, vous avez des abstractions dans votre code. Cela signifie que certains Bahaviour et des données pourraient être généralisés et encapsulés de type général - cela pourrait être une interface. Vous avez déjà mentionné des morceaux similaires - pourrait-il y avoir une interface appelée? Aussi avec des mouvements - pourrait-il y avoir une interface appelée mouvement?
Par exemple, une interface pièce peut avoir des méthodes courantes telles que: P>
public interface Piece {
String getName();
Position getPosition();
List<Movement> getAvailableMovements();
void move(Movement movement);
BufferdImage getImage();
}
C'est toujours une bonne pratique pour programmer une interface car elle formalise une classe pour avoir un ensemble de méthodes requis. Il permet également de recueillir des cours qui ont mis en place une interface commune pour travailler ensemble. Imaginez que vous ayez eu de nombreux objets qui avaient une méthode SetColor. Au lieu de devoir régler la couleur individuellement ou à travers des listes de chaque type d'objet, vous aurez pu les faire suivre:
Interface ColorSetter {
public void setColor(Color color);
}
class Foo implements ColorSetter {
//details omitted
}
class Bar implements ColorSetter {
//details omitted
}
List<ColorSetter> colorSetters = new ArrayList<>();
colorSetters.add(new Foo());
colorSetters.add(new Bar());
// later...
for (ColorSetter c : colorSetters) {
c.setColor(Color.blue);
}
Les interfaces dans tout type de langage de programmation sont un contrat pour spécifier le comportement et la communication abstraite entre 2 parties. Lorsque vous concevez une solution logicielle, vous souhaitez la construire après les meilleures pratiques et motifs, il sera donc plus facile de maintenir à l'avenir. p>
En particulier en Java, vous avez des classes abstraites et des interfaces. Interfaces déclarent quelle classe devrait faire (interfaces dans Java8 + fournir des moyens de spécifier le comportement, les méthodes réelles par défaut, mais je suppose que pour votre affectation à domicile, cela n'est pas encore prévu.) Depuis que vous développez un jeu, cela pourrait être intéressé à résumer la fonctionnalité que toutes les pièces doivent manipuler. Ils devraient savoir comment donner leur emplacement, savoir s'ils sont toujours actifs dans le jeu, de connaître les règles qui s'appliquent à elle. Vous pouvez également résumer les mouvements exécutés pendant le jeu. Chaque mouvement a une pièce ou des morceaux spécifiques auxquels il s'applique, sait quand il peut être exécuté et comment s'exécuter et même comment l'annuler. Votre classe de jeu pourrait également avoir une liste de garder l'historique des mouvements effectués dans le jeu. De cette façon, vous pouvez mettre en œuvre un moyen facile de rembobiner votre jeu jusqu'à un certain point. P>
Vous pouvez étendre vos connaissances en lisant également des principes solides et en vérifiant les modèles de conception de logiciels courants (par exemple, https://refactoring.guru / ). P>
Peut-être que vous pourriez utiliser une interface pour modéliser les pièces (avoir des méthodes telles que GetType (), GetAvailableMOVes (), ISingame (), etc.)
Certaines règles peuvent également être généralisées. Par exemple, certaines personnes sont d'accord sur "capturer" des pièces ennemies qui sont "derrière" et d'autres ne le veulent pas. Vous pouvez avoir des
capturyrule code> avecCANCAPTURE (...); code>. Ouinterface mouvementtrategy {boolean checkmove (pièce P, tableau, lieu de place);} code> qui est différent pour "homme" et "chevaliers", ou si les chevaliers après "attraper" la pièce ennemie doivent "atterrir" après elle ou à n'importe quel champ après cela, ou si des morceaux doivent attraper des ennemis ou non.