OO-Design, offen / geschlossen Prinzip Frage

StackOverflow https://stackoverflow.com/questions/91137

Frage

Ich habe jetzt eine Zeit lang über diese objektorientierte Design Frage nachgedacht und habe nicht in der Lage mit einer zufriedenstellenden Lösung zu kommen, dachte ich so offen für einige Meinungen zu den Massen hier werfen würde.

Ich habe eine Spiel Klasse, die ein rundenbasiertes Brettspiel darstellt, können wir es ähnlich wie Monopoly für die Zwecke dieser Frage annehmen. In meinem Entwurf habe ich eine Spieler Klasse eine Methode TakeTurn enthält.

Spiel Schleifen durch alle Spieler s und ruft die TakeTurn Methode, um alle notwendigen Dinge zu tun, um die Wende zu vollenden. Ich möchte in der Lage, n Anzahl der Spieler zu haben und in der Lage, eine beliebige Anzahl von ihnen zu setzen Computer-Spieler zu sein. So, das war mein Gedanke eine HumanPlayer Klasse zu haben und eine ComputerPlayer Klasse, die beide von Spielern ableiten.

Spiel kennt nur die Spieler Klasse und ruft einfach die TakeTurn Methode auf jedem Spieler in der Reihe. Mein Problem kommt in der Tatsache, dass ComputerPlayer Objekte vollständig automatisiert werden können, das heißt mit dem Monopoly Beispiel zu halten, kann entscheiden, eine Immobilie kaufen einig Stück von Logik. Jetzt, mit dem HumanPlayer Objekt, braucht es eine Eingabe von dem tatsächlichen Benutzer erhalten zu können, eine Eigenschaft zum Beispiel kaufen, die eine andere Schnittstelle zu implizieren scheinen und bedeuten potenziell sollten sie nicht ableiten

Ich habe nicht in der Lage gewesen, eine gute Lösung für das Problem zu kommen, ohne dass die Spiel Klasse kennt die tatsächlichen Implementierungen der verschiedenen Spieler Klassen explizit. Ich kann immer davon ausgehen, in der Spiel Klasse, dass es immer nur Mensch und Computer-Spieler sein wird und es effektiv für die Erweiterung schließen, aber es scheint nicht, wie gut OO-Programmierung.

Alle Meinungen zu diesem Thema gebeten.

War es hilfreich?

Lösung

Ich denke, man sollte nicht die Spielklasse Handelt IO lassen. Auf diese Weise werden die (Blockierung) TakeTurn Verfahren die Mittel zur Umsetzung vom Spielbrett verstecken. es kann andere Objekte verwenden, um mit dem Benutzer zu kommunizieren.

Alle Spielklassen sollten mich beschäftigen mit dem Zustand des Vorstandes und der Wende. Die Spieler sollten alle einen einzigen Spieler-Schnittstelle implementieren und alle Implementierung aus dem Spiel verstecken.

Andere Tipps

Wenn das Spiel ist das Spiel Zustand Verwaltung und Sich I / O, ist das Spiel zu viel zu tun.

Sie wollen Spiel fest auf nur Regeln und Wendungen und Zustandsänderungen fokussiert werden. Spiel nicht weiß, was ein Spieler ist; er weiß nur, dass es Spieler hat.

Sie wollen Spieler das Spiel Zustand und führen Sie die rechtlichen Schritte während ihre Schwünge zu untersuchen.

Menschliche Spieler und das Spiel als Ganzes beide eine gemeinsame E / A-Paket, das Spiel Zustand zeigt und fordert die Menschen für ihren Einsatz.

Sie können gut nutzen das Java Observable, indem der E / A-Paket ein Observer des Spiels. Auf diese Weise, Game Zustandsänderungen an das I / O für die Anzeige oder die Protokollierung oder beide angegeben.

Ich würde wahrscheinlich nicht zwei HumanPlayer und ComputerPlayer Klassen, sondern eine einzige Player Klasse, die zum Zeitpunkt der Erstellung mit der richtigen Eingangsstrategie konfiguriert ist.

Die Art und Weise die Spieler Informationen erhalten seine Bewegung in der nächsten Runde des Spiels zu entscheiden, ist die nur Sache, die (von der ursprünglichen Problembeschreibung, zumindest) variiert, so verkapseln nur, dass in einem getrennte Abstraktion.

Wie auch immer Klasse auf hoher Ebene, die das Spiel einrichtet sollte auch die beiden Gruppen von Spielern schaffen (ein Mensch, eine andere computersimulierten), mit der richtigen Eingangsstrategie für jeden, und dann einfach diese Spielerobjekte, um das Spiel-Objekt geben . Die Spielklasse wird dann rufen Sie nur die TakeTurn Methode auf der gegebenen Liste der Spieler, für jede neue Wendung.

Statt das Spiel Klasse zu sagen, es ist immer nur ein Mensch, warum lassen Sie es nicht, dass die Eingabe während des Menüs / Initialisierung des Spiels bekommen? Wenn es mehr Spieler gibt, die über irgendeine Form von Eingang (wählen Spieler im Menü) entschieden werden kann, vor dem Spiel Klasseninitialisierung.

Die Schnittstelle, die Spieler präsentiert Spiel ist orthogonal zu dem Verhalten abgeleitet Spieler Klassen.

Die Tatsache, dass die Umsetzung von TakeTurn variiert in Abhängigkeit vom konkreten Typ der Spieler Objekt sollte kein Grund zur Sorge sein.

Ich denke, die Game Klasse sollte nicht Sorge über alle Implementierungen der Spielerklassen, und auch die Benutzeroberfläche ignorieren.

Jede Benutzereingabe muss vom HumanPlayer Klasse behandelt werden.

Ich würde sagen, die Spiel Klasse sollte es egal, ob dies ein Computer-Spieler oder ein menschlicher Spieler ist. Es sollte immer anrufen TakeTurn auf der nächsten Spielerklasse. Wenn dies ein menschlicher Spieler ist, ist es in der Verantwortung der Spieler Klasse, mit dem Benutzer zu kommunizieren und die Benutzer fragen, was zu tun ist. Das heißt, es wird blockiert, bis der Benutzer seinen Entschluß gefaßt. Da in der Regel UI Interaktion statt im Hauptthread einer Anwendung erfolgt, ist es nur wichtig, dass eine Blockierung TakeTurn wird die Anwendung als Ganze nicht blockieren, sonst Eingabe Benutzer nicht während verarbeitet werden kann Spiel wartet auf TakeTurn .

Statt der Spiel Klasse aufrufen TakeTurn auf alle Spieler die Spieler nennen sollte TakeTurn auf Spiel Klasse und die Spiel Klasse sollte überprüfen, ob der richtige Spieler seinen Zug nimmt.

Dies sollte die User helfen lösen und Computer Spieler Problem.

Im bin nicht sicher, ob dies ist, was Sie wollen 

public abstract class Player 
{
  int position;
  DecisionMaker decisionDependency;

  ...

  public void TakeTurn()
  {
    position += RollDice();
    GameOption option GetOptions(position);
    MakeDescion(option);
  }

  protected int RollDice()
  {
    //do something to get the movement
  }

  protected abstract void MakeDecision(GameOption option);

}

Public class ComputerPlayer : Player
{
  public ComputerPlayer()
  {
    decisionDependency = new AIDecisionMaker();
  }

  protected override void void MakeDecision(GameOption option)
  {
    decisionDependency.MakeDecision(option);
    //do stuff, probably delgate toan AI based dependency
  }
}

Public class HumanPlayer : Player
{
  public HumanPlayer()
  {
    decisionDependency = new UIDecisionMaker();
  }

  protected override void void MakeDecision(GameOption option)
  {
    decisionDependency.MakeDecision(option);
    //do stuff, probably interacting with the a UI or delgate to a dependency
  }
}
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top