OOP Methoden für mehrere Objekte

[LalaPila]

Hallo!

Ich programmiere gerade mit Freunden etwas und ich habe Schwierigkeiten mit einem Problem. Es gibt sicherlich eine schöne Lösung dafür, die mir nicht einfallen möchte. Vielleicht habt ihr ja eine Idee.

Um es besser erklären zu können, versuche ich es mal einem "Spiel"prinzip zu erklären.

Wir haben mehrere Spieler (Objekte), die Eigenschaften besitzen (Name, Alter, usw). Jeder Spieler hat auch Methoden wie z.B. spezialWaffe oder sowas. Es gibt aber auch verschiedene Rollen. D.h. die Methode spezialWaffe unterscheidet sich von Rolle (Klasse) zu Rolle.

Soweit so gut, jetzt kommt der Knackpunkt. Manche Rollen agieren alleine, manche jedoch gemeinsam (d.h. teilweise entscheiden sie alleine, teilweise in der Gruppe). Also man kann nicht einfach von jedem Objekt die Methode spezialWaffe aufrufen.

Ist es jetzt intelligent die Methoden generell in die Klassen reinzuhauen, oder sollte man das dann trennen? Statische Methoden/Atrribute machen wohl ja auch kein Sinn.

Ich hoffe, ich konnte euch es verständlich erklären .

Danke und Gruß!

 

[Michael...]

Soweit so gut, jetzt kommt der Knackpunkt. Manche Rollen agieren alleine, manche jedoch gemeinsam (d.h. teilweise entscheiden sie alleine, teilweise in der Gruppe). Also man kann nicht einfach von jedem Objekt die Methode spezialWaffe aufrufen.

Was muss man sich darunter vorstellen? Eine Waffe, die von mehreren bedient werden muss? z.B. Spieler1 und Spieler2 müssen beide gleichzeitig einen Knopf drücken?
Dann benötigen beide Spieler eine Referenz auf das selbe Waffenobjekt und die Waffe selbst muss sich merken welcher Spieler gerade seinen Knopf drückt und welcher nicht.

 

[Aldimann]

Naja ich würde auf jeden Fall schonmal vererbung nutzen.

Es gibt eine generelle Klasse Spieler ggf. abstract. Dann Klassen für die verschiedenen Rollen die dann eben die speziellen Methoden bereit stellen...

dazu sollte man dann noch nen konzept haben wie dieses "in der Gruppe entscheiden" aussehen soll...

Hoffe ich konnte ein bißchen helfen ...

Grüße

 

[JanHH]

Klingt grundsätzlich nach einer relativ komplexen Struktur von Objekten, die sowohl einzeln als auch in Gruppen angeordnet sein können, mit diversen Beziehungen untereinander. Hierfür sollte man erstmal eine Struktur des Objektmodells erzeugen, also sich genau überlegen, was für ein Datenmodell da eigentlich vorliegt. Auf Basis dessen kann man dann eine Klassenstruktur erzeugen, die genau dieses Modell abbildet. Und dann sind die Probleme eigentlich gelöst. Grundsätzlich nimmt man dafür natürlich schon Klassen bzw. Objekte, deren Methoden, Vererbung usw ;-).

Also als Beispiel.. es könnte eine abstrakte Oberklasse "AbstractPlayer" geben, die die Funktionen eines Spielers (teilweise konkert implementiert, teilweise abstrakt) bereitstellt, und davon abgeleitet gibt es den "IndividualPlayer", der einen einzelnen Spieler repräsentiert, und die "PlayerGroup", in der mehrere Spieler zu einer Gruppe zusammengefasst sind. Und so weiter und so fort. Eigentlich eine schöne Übung in objektorientierten Modellieren .

 

[LalaPila]

Eine Waffe, die von mehreren bedient werden muss? z.B. Spieler1 und Spieler2 müssen beide gleichzeitig einen Knopf drücken?
.

Du kennst doch sicher "Der Besuch der alten Dame"? Ill wird am Schluss von den Bewohnern umgebracht. Es war jeder aber auch keiner.
Ne, in dem Beispiel ist es schon anders. Die Entscheidung an sich wird außerhalb des Programmes entschieden. Nur man möchte ja nur einmal angeben, für wen sich die Spieler der Klasse "Orks" entschieden haben und nicht für jeden Einzelnen (es ist ja auch immer der gleiche).

[...]in der mehrere Spieler zu einer Gruppe zusammengefasst sind[...]

Wie sähe das konkret aus?

Macht es Sinn mit Interfaces zu arbeiten?

Mir fehlt so ein wenig der letzte Tipp :/. JanHH, dein Post war aber auch sehr hilfreich.

Habe gerade beruflich viel zu tun, weshalb ich bisher keine Zeit gefunden hatte zu antworten.

 

[pausch]

Was hältst du denn davon, wenn du ein Interface der Figur machst und für jede unterfigur ein weiteres Interface, was dann vom Interface Figur ist. So kannst du zusätzlich eine art Hirarchie einbauen...

 

[JanHH]

Naja z.B. so..

abstract class AbstractPlayer
{
   public abstract void doSomething();
}

class IndividualPlayer extends AbstractPlayer
{
   public abstract void doSomething()
   {
      // hier wird nun was getan, z.B. Waffe ausgelöst etc.
   }
}

class PlayerGroup extends AbstractPlayer
{
   private Map<AbstractPlayer> players;

   public abstract void doSomething()
   {
      // hier wird nun was getan, z.B. Waffe ausgelöst etc.
   }
}

Das wäre dann übrigens das "Composite pattern" (Kompositum (Entwurfsmuster) ? Wikipedia).

Ansonsten sehr empfehlenswert, das gute alte "Design patterns"-Buch von Gamma und co. Bei Wikipedia gibts auch eine gute Übersicht über diverse Patterns. Wenn man mit sowas bisher noch nicht so viele Erfahungen hatte, ist es sehr empfehlenswert, sich mit sowas mal zu beschäftigen.

 

[Gregorrr]

Ansonsten sehr empfehlenswert, das gute alte "Design patterns"-Buch von Gamma und co. Bei Wikipedia gibts auch eine gute Übersicht über diverse Patterns. Wenn man mit sowas bisher noch nicht so viele Erfahungen hatte, ist es sehr empfehlenswert, sich mit sowas mal zu beschäftigen.

Das alte Buch von Gamma - Ja, aber nur wenn du Masochist bist

Head First Design Patterns ist so das beste Buch für dieses Thema, IMHO. Ist halt neuer und genau für Java zugeschnitten. Und lustiger

 

[JanHH]

Was hat denn das Design Patterns-Buch mit Masochismus zu tun? Ich finds ausgesprochen gut geschrieben und verständlich. Ist zwar nicht mehr ganz neu, aber die Thematik ist ja auch quasi zeitlos..

 

[Gregorrr]

Was hat denn das Design Patterns-Buch mit Masochismus zu tun? Ich finds ausgesprochen gut geschrieben und verständlich. Ist zwar nicht mehr ganz neu, aber die Thematik ist ja auch quasi zeitlos..

Zitat aus GoF: "A word of warning and encouragement: Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing! Rememver that this isn't a book to read once and put on a shelf. We hope you'll find yourself referring to it again and again for design insights and for inspiration."

Nimmt man nun an, dass die meisten Leute wenig mit C++ und Smalltalk in Berührung kommen, sondern viel mehr Java 1. Sprache der Wahl ist - schließlich ist das hier auch ein Java Forum - warum sollte man nicht gleich ein Buch nehmen, wo die Beispiele in Java sind, netter formuliert sind und einfach nachzumachen sind?

 

[bobbsen]

Du kannst aber doch schlecht ein Was-ist-Was Buch (Heads First) mit einem Lexikon (Entwurfsmuster) vergleichen. Die gehen zwar beide ums gleiche Thema, aber das eine ist nen Buch über die Muster, wie man sie entwickelt, etc., das andere ist nen Nachschlagewerk über sie.

Natürlich ist Heads First speziell für Java-Anfänger leichter, da es die Beispiele auch noch in Java entwickelt, aber wenn man mit den Klassendiagrammen erstmal zurecht kommt, kann man die meisten Muster auch anhand der Texte und Diagramme verstehen, dann ergibt der C++/Smalltalk-Teil auch so einen Sinn, ohne die Sprache zu können.

 

[Gregorrr]

Du kannst aber doch schlecht ein Was-ist-Was Buch (Heads First) mit einem Lexikon (Entwurfsmuster) vergleichen. Die gehen zwar beide ums gleiche Thema, aber das eine ist nen Buch über die Muster, wie man sie entwickelt, etc., das andere ist nen Nachschlagewerk über sie.

Natürlich ist Heads First speziell für Java-Anfänger leichter, da es die Beispiele auch noch in Java entwickelt, aber wenn man mit den Klassendiagrammen erstmal zurecht kommt, kann man die meisten Muster auch anhand der Texte und Diagramme verstehen, dann ergibt der C++/Smalltalk-Teil auch so einen Sinn, ohne die Sprache zu können.

Genau auf den Punkt gebracht. das Heads First Buch ist ein sehr guter Einstiegspunkt in die Materie in Java. Dein abwertendes "Was-ist-was" lasse ich mal so stehen, damit kann ich nichts anfangen. Natürlich gibt es Literatur die ist zugänglicher - weil sie zugänglicher sein will, deswegen muss nicht schlechter sein. Es hat einfach eine andere Intention.
Als Nachschlagewerk für Java gibt es andere, neuere Bücher, die sind besser. Wiederum: andere Intention => Nachschlagewerk für Java.
Nichtsdesto trotz, es schadet mit Sicherheit nicht das Original gelesen zu haben. Ganz im Gegenteil, wer so viel Zeit hat, sollte das unbedingt lesen. Aber als Einstieg für jemanden der nur Java bisher programmiert hat?

 

[maki]

"Design Patterns. Elements of Reusable Object-Oriented Software" von der GoF ist immer noch DIE Referenz für Design Patterns, u.a. wegen des "alexandrinischen" Formats, selbst wenn die Beispiele in C++ sind und die Diagramme keine UML Diagramme (gabs damals noch nicht) sind.
Es sind nicht alle Design Patterns darin enthalten (es finden sich ständig neue), dafür ist eines sehr umstritten,

Head First Design Patterns dagegen ist keine Referenz, sondern ein Einsteigerbuch zu diesem Thema, steht auch explizit so drinnen, das "beste Buch zu diesem Thema" ist es sicherlich nicht, "das beste Buch für Einsteiger" wäre möglich.
Ist nicht abwertend gemeint, "aber diese beiden Bücher spielen nicht mal in derselben Liga" ist sicherlich nicht übertrieben.

Man sollte aber nicht vergessen das DP keine Kochrezepte sind und die Fähigkeit des Programmierens (Handwerk) nicht ersetzen, sonst wird "Design Pattern" schnell mal mit "Bullshit Bingo" verwechselt

 

[bobbsen]

Dein abwertendes "Was-ist-was" lasse ich mal so stehen, damit kann ich nichts anfangen.

Da hast du mich falsch verstanden, das "Was-ist-was" war nicht abwertend gemeint, ich konnte mit beiden Bücher was anfangen ;-)

Ich wollte eigentlich nur sagen, dass beide Bücher ihre Daseins-Berechtigung haben, Head first ist aber zum Lernen (Wie als Kind/jugendlicher die Was-ist-was Bücher), Entwurfsmuster ist wie ein Lexikon auch später noch zum Nachschlagen verwendbar.

 

[JanHH]

Welches Pattern ist denn umstritten?

Ich find, beim Lesen von "design patterns" fallen gleich mehrere Groschen, wenn man vorher schon versucht hat, bestimmte Softwareprobleme auf eigene Faust zu lösen. Ging mir z.B. bei der Frage "wie implementiert man eine undo-Funktion" so (command pattern). Also wenn man nicht im Studium oder in der Ausbildung mit dem Thema zu tun hatte, sondern quasi Programier-Autodidalt ist, ist eine Beschäftigung damit schon sehr empfehlenswert.

 

[Lit-Web]

Um mal aufs Problem zurück zu kommen. Auf alle Fälle würde ich ein I_Player Interface nuetzen und das den speziellen Player Klassen implementieren. Die abstrakte Player Klasse ist natürluch auch sinnvoll, da kannst recht viele Code Redundanzen vermeiden und alles mit unterbringen was eh alle Player gemeinsam haben.

In dem Problem mit den Waffen würde ich auch über ein Strategie Pattern nachdenken, denn verschiedene Waffen haben verschiedene Bedienalgorythmen und je nach Situation kann dann der Algorythmus gewechselt werden. Grad in einem Spiel können ja immer recht schnell neue Situationen auftreten.

Einen Sinn für ein Composite Pattern sehe ich hier nicht, weil die Zielstellung ist das z.B. eine Waffe von zwei Spielern bedient werden muss. Z.B. nehmen wir einen Panzter, da muss einer fahren und der andere das MG bedienen und noch einer die Kanone. Da hast du zwar drei Spieler, aber die hängen nicht in einer Hierarchie zusammen. Denn kein Player ist Parent eines Childs. Composite macht aber eben nur in solchen Fällen einen Sinn wo wirklich eine Hierarchie abgwbildet werden soll.

Und zum Thema Buch finde ich das Enterprise Architektures von Martin Fowler sehr gut. Ist Sprachunabhängig, aber trotzdem gut erklärt. Man muss sich eben mit UML richtig auseinandersetzen und dann versteht man auch vieles davon.

Gruß Lit-Web

 

[Gregorrr]

Welches Pattern ist denn umstritten?

Ich find, beim Lesen von "design patterns" fallen gleich mehrere Groschen, wenn man vorher schon versucht hat, bestimmte Softwareprobleme auf eigene Faust zu lösen. Ging mir z.B. bei der Frage "wie implementiert man eine undo-Funktion" so (command pattern). Also wenn man nicht im Studium oder in der Ausbildung mit dem Thema zu tun hatte, sondern quasi Programier-Autodidalt ist, ist eine Beschäftigung damit schon sehr empfehlenswert.

Erich Gamma: "I'm in favor of dropping Singleton. Its use is almost always a design smell."

Neue Design Patterns, die hinzukommen würden nach Gamma wären: Null Object, Type Object, Dependency Injection, Extension Object/Interface.

Nochmal: Das original DP Buch ist nicht das optimale für Java. Z.B. hat "Software Architecture Design Patterns in Java" mehr Patterns, UML-Beschreibung, Beispielprogramme in Java.

TAOCP ist mit Sicherheit noch ein Level über dem GoF Buch, trotzdem würde ich es einem Anfänger nicht empfehlen. Es muss immer das jeweilige Buch im jeweiligen Kontext begutachtet werden.
[OK, ich bin raus aus der Diskussion hier, wenn ihr GoF lesen wollt, ist das ne super Sache, aber bitte neuere Literatur noch hinzufügen - es hat sich seit dem viel verändert, und als Einsteiger würde ich das Head First Buch empfehlen, zudem noch eins als Java-Referenz.]

 

[Gregorrr]

Um mal aufs Problem zurück zu kommen. Auf alle Fälle würde ich ein I_Player Interface nuetzen und das den speziellen Player Klassen implementieren. Die abstrakte Player Klasse ist natürluch auch sinnvoll, da kannst recht viele Code Redundanzen vermeiden und alles mit unterbringen was eh alle Player gemeinsam haben.

In dem Problem mit den Waffen würde ich auch über ein Strategie Pattern nachdenken, denn verschiedene Waffen haben verschiedene Bedienalgorythmen und je nach Situation kann dann der Algorythmus gewechselt werden. Grad in einem Spiel können ja immer recht schnell neue Situationen auftreten.

Einen Sinn für ein Composite Pattern sehe ich hier nicht, weil die Zielstellung ist das z.B. eine Waffe von zwei Spielern bedient werden muss. Z.B. nehmen wir einen Panzter, da muss einer fahren und der andere das MG bedienen und noch einer die Kanone. Da hast du zwar drei Spieler, aber die hängen nicht in einer Hierarchie zusammen. Denn kein Player ist Parent eines Childs. Composite macht aber eben nur in solchen Fällen einen Sinn wo wirklich eine Hierarchie abgwbildet werden soll.

Gruß Lit-Web

Sehe ich genauso wie Du. Das Problem ist eher die weiche Formulierung der Ausgangsituation vom OP.
Aber ich würde eher dazu tendieren, austauschbare Algorithmen zur Laufzeit zu haben => Strategy Pattern.

Das mit den Gruppen ist einfach zu schwammig formuliert, IMHO.