Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Aber was willst du mir denn jetzt damit sagen, dass jedes Nomen ein Kasten darstellt? Wofür steht denn ein Kasten in deinem Sinne? Und wozu dient der Pfeil?
Beides benutzt du in deinem Diagramm schon – benutzt du das, ohne zu wissen, was es darstellt?
Abgesehen davon steht es sogar in meinem Beitrag in der Zeile darüber: "Jedes Nomen ist jetzt ein Typ (=Klasse, Enum oder primitiver Typ wie Zahl/String/boolean), jedes Unterstrichene ist ein Feld in einem der Typen." Also, "Kasten"=Typ, "Pfeil"="besitzen" (=Relation).
2. Was meinst du mit "...wenn dem so ist, kannst du es als eigener Typ in dem Diagramm entfernen und direkt als ...". Wenn du ja sagst, dass jedes Nomen ein Typ ist und sagst, dass der nickname als Stringtyp als eigener Typ in dem Diagramm entfernt werden kann und direkt als Attribut in den besitzenden Typ eingetragen werden soll ? Der Nickname ist doch als Attribut dem besitzenden Typen(Player) beigefügt???
Am Anfang: Ein Kasten "Spieler", ein Kasten "Nickname", dazwischen ein Pfeil (von Spieler auf Nickname zeigend).
Nickname hat keinen ausgehenden Pfeil (und keine Attribute, die du in dem Schritt erstellst) => daran erkennst du, das es ein primitiver Typ ist, und als primitiver Typ kommt da String in Frage => "Kasten Nickname" entfernen und Nickname direkt dem Typen Spieler hinzufügen.
Ein Labyrinth hat eine Höhe und eine Breite. Es besitzt außerdem unbekannte, nicht zugängliche Felder, dann Wände und noch freie Wege.
Die verschiedenen Items befinden sich mit ihren Scores ebenfalls im Labyrinth.
Es gibt "Felder", die sind einfach da, man kann sie nicht betreten und man weiß nicht was es ist?
Dann Wände, da kann man vermutlich nicht durchgehen?
Und Wege, die sind dann wohl das einzige zum drüber laufen?
Und Baits liegen jetzt wo? Einfach so im Labyrinth oder auf Wegen oder auf nicht zugänglichen Feldern?
Wie sieht der Weg von Text ("Ein Labyrinth hat eine Höhe und eine Breite. Es besitzt außerdem unbekannte, nicht zugängliche Felder, dann Wände und noch freie Wege.
Die verschiedenen Items befinden sich mit ihren Scores ebenfalls im Labyrinth.") bis dahin aus?
Baits liegen auf zugänglichen Feldern.
Nur weiß ich nicht wie ich das umsetzen kann, ist das erste Projekt, was ich mache mit großerem Kontext deshalb bitte ich da auch um etwas Verständnis
Und welchen Schritt habe ich übersprüngen, seit wann soll man aus einem Attribut einen Kasten(stellvertretend für eine Klasse) verwenden, wäre ggf. echt gut wenn du flüssig antworten würdest, wenn du schon helfen möchtest. Die Art und Weise, wie du argumentierst und dann mittendrin wieder nichts schreibst ist doch nicht zielführend wenn man schon ein Helferkomplex hat. Ich weiß nicht warum du dich so komisch verhältst. Ich bin in der Lage zu abstrahieren, was du mir mit deinen Antworten sagen möchtest, aber du gibst mir Antworten, die sich nicht explizit auf das beziehen was, ich zuerst erfragen wollte: Wie setze ich die Wände usw. um??? Da bringt es mir nichts zu wissen was Typen sind(unterstrichene Nomen). Ich bin wohl selbst in der Lage einfache Attribute den Klassen zuzuordnen, deshalb verstehe ich die Gewichtung des Textes nicht, wäre echt gut wenn du mal auf mich versuchst einzugehen, anstatt nur von dem überzeugt zu sein, was du mir sagst.
Was du meinst geht bestimmt in diese Richtung (vorheriges Maze, dort sind noch ein paar Dinge fehlend, die in dem anderen dabei sind), aber hier geht um das Status Model, welches ich meine. @mrBrown
wäre ggf. echt gut wenn du flüssig antworten würdest, wenn du schon helfen möchtest. Die Art und Weise, wie du argumentierst und dann mittendrin wieder nichts schreibst ist doch nicht zielführend wenn man schon ein Helferkomplex hat
Du kannst das doch ganz frei aufbauen, zumindest habe ich beim überfliegen diesbezüglich nichts in den pdfs gefunden (Aber ich muss zugeben, dass ich die wirklich nur ganz ganz schnell überflogen habe ...)
Stell Dir das doch einfach bildlich vor. Du hast also sowas wie Objekte. Du hast also ein Spielfeld mit x mal y Feldern. Ein Feld hat ein bestimmten Typ. Und den modellierst Du richtig! Keine "Abkürzungen" mit Zeichen oder so! Also wenn es eine feste Menge an FeldTypen gibt, dann modellierst Du das auch so (Also lass das Enum! Aber das ist kein Feld sondern ein FeldTyp. Korrekte Benennung beachten! Und so ein feldTyp kann dann auch durchaus wissen, wie man sich als Zeichen oder String darstellt. Das könnte man bei der Definition des Enum mit vorgeben und man könnte eine statische Methode haben, um aus einem Zeichen / einer Zeichenkette das Enum zu bekommen.)
Also hast Du x mal y etwas vom Typ Feld. Wie kannst Du das abbilden? Kennst Du eine Datenstruktur, die dies erlaubt?
Und dann hast Du Felder. Ein Feld ist gekennzeichnet durch einen Typ. Und dann kann da etwas auf dem Feld sein. Da wäre dann eine Frage: Wie viele Elemente?
- 0..1? (Also kein Element oder max 1 Element?)
- 1?(Also immer genau ein Element?)
- 0..n? (also beliebig viele Elemente?)
Das kann man dann entsprechend modellieren. Das 0..1 und 1 ist fast gleich. Das wäre eine Referent die eben null sein kann oder nicht.... Und für den letzten Fall wäre die Frage: Kennst Du irgend ein Konstrukt, in das Du 0, 1 oder beliebig mehr Elemente packen könntest?
Und welchen Schritt habe ich übersprüngen, seit wann soll man aus einem Attribut einen Kasten(stellvertretend für eine Klasse) verwenden, wäre ggf. echt gut wenn du flüssig antworten würdest, wenn du schon helfen möchtest. Die Art und Weise, wie du argumentierst und dann mittendrin wieder nichts schreibst ist doch nicht zielführend wenn man schon ein Helferkomplex hat
Das große Problem ist, dass wir Dir keine Lösung vorgeben wollen. Damit würdest du nichts lernen. Also haben wir das Problem, dass wir erst einmal erkennen müssen, an welcher Stelle es bei Dir hakt. Um dann da gezielt zu helfen. Und zwar so zu helfen, dass Du auf die Lösung kommst.
Im Augenblick denke ich, das Du Probleme hast, Dir das vorzustellen um es dann Sinnvoll zu unterteilen. Mir hat damals "Object Thinking" von Microfot Press als Buch gut gefallen. Das hat das relativ gut erläutert ...
zur Klasse Player:
Jeder Spieler befindet sich an einer Position und schaut in eine der 4 vorhanden Himmelsrichtungen. Jeder Spieler hat eine individuelle Punktzahl und am Anfang beträgt sie 0. Jeder hat eine eigene ID und eine nickname und eine bestimme Koordinate im Maze. Der Spieler muss die Baits einsammeln können (collect()) und dazu muss er sich bewegen können (move()). Außerdem muss ein Spieler sich mit dem Server verbinden können, das Spiel spielen und es auch wieder verlassen können.
Maze:
Ein Labyrinth hat eine Höhe und eine Breite. Es besitzt außerdem unbekannte, nicht zugängliche Felder, dann Wände und noch freie Wege.
Die verschiedenen Items befinden sich mit ihren Scores ebenfalls im Labyrinth.
Ja, wenn du nicht auch mal etwas einstecken kannst, bist du wohl fehl am Platz oder bist du hier um dich überlegen zu fühlen??
Naja, auf das niveau wollen wir nicht zusteuern. Aber wenn jemand helfen möchte, dann doch bitte möglichst so, sodass man das nicht allzu lange warten lässt (zumal das ja im Interesse desjenigen sein sollte, der ja helfen möchte, damit jemand weiterkommen kann).
@JustNobody
Zu #63:
Das mit der statischen Methode verstehe ich nicht, um daraus das Enum zu bekommen.
Um das x mal y vom Typ Feld abbilden zu können kann man ein 2D-Array verwenden.
Zur letzten Frage, ein Konstrukt in das ich 0,1 oder mehrere Elemente packen könnte. Da wäre eine List denkbar oder evtl auch ein normales Array.
Da steht "Es besitzt außerdem unbekannte, nicht zugängliche Felder, dann Wände und noch freie Wege.
Die verschiedenen Items befinden sich mit ihren Scores ebenfalls im Labyrinth", da kommt weder "Status" noch "Model" noch "StatusModel" vor.
(Oder um es deutlicher zu sagen: StatusModel ist Unsinn.)
Ok, das hat sich etwas überschnitten. Was mir bei Dir auffällt ist: Du hast Felder - das wäre dann aber Field und nicht FieldType.
Und die Baits hast Du statt in einem Feld direkt im maze gespeichert. Das geht natürlich auch. Das kann man sich generell so überlegen, wie man möchte.
Ja, wenn du nicht auch mal etwas einstecken kannst, bist du wohl fehl am Platz oder bist du hier um dich überlegen zu fühlen??
Naja, auf das niveau wollen wir nicht zusteuern. Aber wenn jemand helfen möchte, dann doch bitte möglichst so, sodass man das nicht allzu lange warten lässt (zumal das ja im Interesse desjenigen sein sollte, der ja helfen möchte, damit jemand weiterkommen kann).
So kommen wir wohl nicht auf einen Nenner fürchte ich. Generell bist Du es, der etwas will. Du kannst Deine Probleme darstellen und wir können darauf antworten. Und das machen wir generell so, wie wir es für richtig halten. Und bei gewissen Erlebnissen überlege ich mir inzwischen durchaus, manche Threads einfach zu ignorieren. Ich muss niemandem helfen um mich überlegen oder besser zu fühlen. Und ich bin extrem sicher, dass es fast allen, die hier aktiv sind, ebenso geht (ohne @mrBrown, @mihe7 und den vielen Anderen, die hier sehr aktiv sind im Forum zu nahe treten zu wollen: Ich unterstelle dies ihnen und stecke sie damit einfach so in diese "Schublade" ...)
Ein Auto besitzt Kolben. Damit das wahr ist: Dürfen die Kolben im Motorblock sein oder müssen diese dann direkt im Auto sein? Wie man das abbildet ist erst einmal egal. Aber spätestens, wenn man zur Funktionalität kommt, dann wird es relativ schwer. Wenn alles direkt im Auto ist, dann wird das Auto sehr komplex. Daher packt man Funktionalität da hin, wo sie hin gehört. Und dann gibt es Einheiten, die geschlossen funktionieren. Also ein Motor hat schon direkt die Funktionalität eines Motors. Das Auto muss die genaue Funktionalität nicht kennen.
Etwas übertragen wäre dies: Für mich würde ein Feld wissen, was es da für Funktionalität gibt. Ein Feld weiss z.B., ob ein Spieler auf das Feld gehen kann. Das ist eine Logik, die das Maze nicht kennen muss. Das Maze muss nur wissen, wie der Spieler sich bewegen möchte, prüft dann das Zielfeld und wenn er es nicht betreten kann, dann führt es die Bewegung nicht aus.
Das reduziert dann die Funktionalität des Maze, strukturiert den Code, macht ihn lesbar. Und vor allem hast Du keine "Masterklasse", in der alles steckt und alles andere sind nur reine Datenhaltung (Was bei C Strukturen waren). Das ist halt etwas, das man in der Softwareentwicklung vermeiden möchte ...
@JustNobody
Zu #63:
Das mit der statischen Methode verstehe ich nicht, um daraus das Enum zu bekommen.
Um das x mal y vom Typ Feld abbilden zu können kann man ein 2D-Array verwenden.
Zur letzten Frage, ein Konstrukt in das ich 0,1 oder mehrere Elemente packen könnte. Da wäre eine List denkbar oder evtl auch ein normales Array.
In java ist ein Enum eine spezielle Klasse die eigentlich fast alles kann, was auch eine Klasse kann mit wenigen Ausnahmen. So kann man zur Laufzeit keine Instanzen mehr erzeugen. Aber Du kannst Instanzvariablen haben, Klassenmethoden, Konstruktor, ...
Also z.B. sowas:
Java:
public enum TestEnumWithIntValue {
ONE(1),
TWO(2),
THREE(3);
private int intValue;
public int getIntValue() { return intValue; }
TestEnumWithIntValue(final int intValue) { this.intValue= intValue; }
public static TestEnumWithIntValue fromIntValue(final int intValue) {
for (TestEnumWithIntValue enumValue: TestEnumWithIntValue.values()) {
if (enumValue.getIntValue() == intValue) return enumValue;
}
throw new InvalidArgumentException("Value " + intValue + " is not a valid value of TestEnumWithIntValue");
}
}
Das ist jetzt hier im Editor geschrieben worden. Tippfehler bitte ich zu entschuldigen. Ohne IDE kann schon mal etwas schief gehen. Aber das Prinzip wird schnell deutlich. Und die statische Methode der enum gibt halt den passenden Enum Wert zurück.
Ansonsten ist es richtig. 2D Array für die Felder hätte ich auch im Sinn gehabt. Es gibt auch andere Lösungsideen speziell wenn man recht große Felder haben will, aber das würde ich tatsächlich erst einmal so machen. (Eine andere Option wäre mit Koordinaten in einer Map wie Du es bei den Baits gemacht hast. Aber das 2d Array ist ok, so Du nicht z.B. sehr viele "UNKNOWN" Felder hast, die Du gerne weglassen möchtest....
Und das mit der Liste ist auch korrekt. Das würde ich in das Feld mit einbauen. Ggf. mit einer null Möglichkeit falls es nur sehr begrenzt diese Baits gibt. Die List brauchst Du aber nur, wenn Du auf einem Feld mehrere Baits haben kannst. Ist das nicht der Fall, dann reicht eine einfache Referenz.
Auch in "Ruhe bewahren"? Dann hätte ich ggf. Interesse Aber evtl. wäre es einfacher, im lokalen DNS Server die Domain java-forum.org zu blocken/umzuleiten bzw ein lokaler Yoga- / Meditation Lehrer verlangt ggf. weniger Oder bau mir eine Seite, die einfach nur ein Meerblick mit Meeresrauschen als Video abspielt ... und auf die leite ich um ... so als Kombination aus beidem
Auch in "Ruhe bewahren"? Dann hätte ich ggf. Interesse Aber evtl. wäre es einfacher, im lokalen DNS Server die Domain java-forum.org zu blocken/umzuleiten bzw ein lokaler Yoga- / Meditation Lehrer verlangt ggf. weniger Oder bau mir eine Seite, die einfach nur ein Meerblick mit Meeresrauschen als Video abspielt ... und auf die leite ich um ... so als Kombination aus beidem
@JustNobody
Ich versuche mal das bis morgen umzusetzen zumal ich jetzt eh afk gehen muss. Ich danke für die Hilfe und komme morgen nochmal darauf zurück.
Das ist ja in Ordnung, ich will auch etwas, das stimmt, aber es bringt dann ja auch nichts mich bei der Hälfte des Weges stehen zu lassen, wobei ich auch das Empfinden hatte, dass @mrBrown und ich teilweise aneinander vorbei geredet haben bzw. ich vlt. an ihm.
@thecain Ein Helferkomplex ist übertrieben formuliert, aber man gibt Hilfestellungen doch hoffentlich auch , um anderen zu helfen und nicht nur, um weiter dazu zu lernen.
Deine Aussagen kamen evtl. etwas falsch rüber. Ich kann verstehen, dass da etwas Frust entsteht, wenn man hier so hin und her schreibt aber ich hoffe, dass ich auch etwas erläutern konnte, wieso wir so vorgehen und keine Lösungen hin knallen.
Und wenn es um Worte und deren Bedeutung geht, dann kann es durchaus leicht dazu kommen, dass man etwas aneinander vorbei redet. Da wäre mein Tipp, die Worte genau zu überdenken. Denn gerade @mrBrown ist da nach meiner Erfahrung jemand, der hier sehr exakt ist und dem man da durchaus gut zuhören sollte. Das aber einfach nur als meine grobe Einschätzung... wünsche allen ein schönen Abend...
Jeder Spieler befindet sich an einer Position, diese besteht aus x- und y-Koordinate, und schaut in eine der 4 vorhanden Himmelsrichtungen. Jeder Spieler hat eine individuelle Punktzahl und am Anfang beträgt sie 0. Jeder hat eine eigene ID und eine nickname und eine bestimme Koordinate im Maze. Der Spieler muss die Baits einsammeln können (collect()) und dazu muss er sich bewegen können (move()). Außerdem muss ein Spieler sich mit dem Server verbinden können, das Spiel spielen und es auch wieder verlassen können.
Maze:
Ein Labyrinth hat eine Höhe und eine Breite. Es besitzt außerdem unbekannte, nicht zugängliche Felder, dann Wände und noch freie Wege.
Die verschiedenen Items befinden sich mit ihren Scores ebenfalls auf Feldern im Labyrinth."
Jedes Nomen ist jetzt ein Typ (=Klasse oder primitiver Typ wie Enum/Zahl/String/boolean), jedes Unterstrichene ist ein Feld in einem der Typen.
Das kannst du jetzt einfach in einem Diagramm darstellen (jedes Nomen ein Kasten, jedes "besitzen" ein Pfeil). Wenn etwas keine ausgehenden Pfeile hat, ist es meist in primitiver Typ, welche musst du dann entscheiden (zB ist "Nickname" wahrscheinlich ein String), wenn dem so ist, kannst du es als eigener Typ in dem Diagramm entfernen und direkt als "Attribut" in den besitzenden Typen eintragen
Und so ein feldTyp kann dann auch durchaus wissen, wie man sich als Zeichen oder String darstellt. Das könnte man bei der Definition des Enum mit vorgeben und man könnte eine statische Methode haben, um aus einem Zeichen / einer Zeichenkette das Enum zu bekommen.)
Also hast Du x mal y etwas vom Typ Feld. Wie kannst Du das abbilden? Kennst Du eine Datenstruktur, die dies erlaubt?
Und dann hast Du Felder. Ein Feld ist gekennzeichnet durch einen Typ. Und dann kann da etwas auf dem Feld sein. Da wäre dann eine Frage: Wie viele Elemente?
- 0..1? (Also kein Element oder max 1 Element?)
- 1?(Also immer genau ein Element?)
- 0..n? (also beliebig viele Elemente?)
Das kann man dann entsprechend modellieren. Das 0..1 und 1 ist fast gleich. Das wäre eine Referent die eben null sein kann oder nicht.... Und für den letzten Fall wäre die Frage: Kennst Du irgend ein Konstrukt, in das Du 0, 1 oder beliebig mehr Elemente packen könntest?
das verstehe ich nicht, erst soll ich eins verwenden und dann nicht ? Des Weiteren verstehe ich nicht, die Feldtypen gehören einem Feld an (das könnte doch auch einfach das Maze sein (2D-Array?) ? Und zu der Frage wie ich ich die Elemente in das Feld packe, hatte sich ja herauskristallisiert, dass ein normale Array dies erfüllen würde, dementsprechend müsste ich eine Klasse mit den Baits(gem, coffee, trap...) erstellen, diesen ihren Wert zuweisen, wodurch sie ein integer wären. Dann müsste ich ja im nächsten Schritt eine Instanz von der Klasse "Baits" bilden in der "Feld(Maze???)"-Klasse damit das Feld verschiedene Elemente der Baits aufnehmen kann ?
Ein Auto besitzt Kolben. Damit das wahr ist: Dürfen die Kolben im Motorblock sein oder müssen diese dann direkt im Auto sein? Wie man das abbildet ist erst einmal egal. Aber spätestens, wenn man zur Funktionalität kommt, dann wird es relativ schwer. Wenn alles direkt im Auto ist, dann wird das Auto sehr komplex. Daher packt man Funktionalität da hin, wo sie hin gehört. Und dann gibt es Einheiten, die geschlossen funktionieren. Also ein Motor hat schon direkt die Funktionalität eines Motors. Das Auto muss die genaue Funktionalität nicht kennen.
Etwas übertragen wäre dies: Für mich würde ein Feld wissen, was es da für Funktionalität gibt. Ein Feld weiss z.B., ob ein Spieler auf das Feld gehen kann. Das ist eine Logik, die das Maze nicht kennen muss. Das Maze muss nur wissen, wie der Spieler sich bewegen möchte, prüft dann das Zielfeld und wenn er es nicht betreten kann, dann führt es die Bewegung nicht aus.
dass das hier gilt, weshalb es eine eigene Feldklasse geben muss. Dementsprechend würden dort die Baits durch ein 1D-Array vom Typ Baits modelliert werden und die Feldtypen würde man dann als welchen Datentyp in Form eines Attributs angeben? (Die Frage habe ich ja schon im Screen gestellt).
Position hat deshalb keine ausgehenden Pfeile, da du x und y direkt als Attribut geschrieben hast
Erster Schritt:
Dann für alle "Blätter" (ohne ausgehende Kanten) den Wertebereich festlegen (hab ich oben nicht extra geschrieben, das explizit noch mal zu machen ist hier aber sinnvoll):
Score: 0 - N
ID: irgendeine ganze Zahl
Nickname: Irgendein Text
Himmelsrichtung: N, O, S oder W
X: irgendeine ganze Zahl
Y: irgendeine ganze Zahl
Wertebereich ist nahezu immer entweder Text, Zahl, Wahr/Falsch oder eine feste Menge an Werten.
Für jedes einzelne davon kann man das meist noch weiter einschränken: Zahl kann zb "Ganze Zahl zwischen 5 und 9" oder "Kommazahl kleiner als 5" sein, Text kann sowas sein wie "Text mit mindestens 5 Zeichen" oder "nur Alphanumerisch".
Das ganze möglichst genau aufschreiben ist in jedem Fall sinnvoll, irgendwann ist jede Einschränkung relevant (auch wenn man sie leider oftmals unter den Tisch fallen lässt...).
Man kann dabei auch feststellen, dass es keinen sinnvollen, begrenzten Wertebereich gibt, in dem Fall lässt man es einfach wie es ist. Sieht man potentiell später noch mal.
Aus dem Wertebereich den Typ ableiten:
Score: int
ID: int
Nickname: String
Himmelsrichtung: Enum mit N, O, S oder W
X: int
Y: int
Theoretisch kann man auch Score, ID, Nickname etc als eigene Klasse behalten.
Ein Score ist eben nicht einfach nur ein int, zB kann der Score ja nicht negativ sein (nehm ich einfach mal an). Daher kann es Sinn haben, eine eigene Klasse Score zu haben, die genau das sicherstellt, die dann zB Methoden wie erhöhe oder verringere hat. In der Klasse kann das dann ein int sein – nach außen sieht man aber nur "Score".
Gleiches für den Nickname, nicht jeder String ist auch ein gültiger Nickname, zB muss ein Nickname immer aus mindestens einem Zeichen bestehen und der Anfang und das Ende müssen sichtbare Zeichen sein, Zeilenumbrüche will man vermutlich auch verhindern und es sollte vermutlich eine maximale Länge geben – also eigene Klasse, die genau das sicherstellt, die dann intern wieder einen String benutzt.
Wird aber von vielen auch als schlechtes Design angesehen.
Und dann das Diagramm entsprechend ändern:
Bis dahin käme man ohne jegliche Java-Kenntnisse, mit minimalen Java-Kenntnissen tippt man das jetzt im Nu runter
Da zeigen sich jetzt die Mängel in der Natürlichsprachlichen Beschreibung
"Feld" wird offensichtlich für mehrere verschiedene Dinge benutzt; einmal ist es das ganze Labyrinth, dann ist es etwas "nicht zugänliches", und zusätzlich liegen auch noch die Baits drauf.
Man könnte das ganze zB etwas anders beschreiben:
Ein Labyrinth hat eine feste Größe, diese setzt sich aus Breite und Höhe zusammen. Ein Labyrinth besteht wie ein Schachfeld aus einzelnen Feldern. Jedes Feld ist dabei entweder ein Weg, eine Wand, oder ein "unbekanntes, nicht zugängliches" Feld. Auf einem Feld kann außerdem ein Bait liegen. Ein Bait hat dabei eine (negative oder positive) Punktzahl.
@mrBrown
Wie war das nochmal mit der Instanzbildung von enums? Denn um das enum "viewDir" mit der Klasse Player zu verbinden, muss
ich ja in der Klasse Player eine Instanzvariable erzeugen von "viewDir".
Neben allen Diskussionen über das Klassendesign, ist es doch aus interessant, wie das Labyrint überhaupt gespeichert werden soll.
Oder anders gefragt: Was ist die "Position" einer Mauer und was ist die "Position" eines Spielers?
Auf einem karierten Blatt Papier würde ich die Mauern auf die Linien zeichnen und die Spieler in die Kästchen. Damit habe ich aber doch zwei unterschiedliche Arten von "Positionen".
Ein Kompromiss könnte sein, dass ich die "Linien" und "Kästchen" gemeinsam durchnummeriere - wie auf folgendem Bild:
Dann sind aber für bestimmte "Teile" nur bestimmte Positionen erlaubt:
waagerechte Mauern: (gerade x ungerade)
senkrechte Mauern: (ungerade x gerade)
Spieler-Position: (ungerade x ungerade)
nicht benutzt: (gerade x gerade)
Und dies sollte wiederum im Klassenmodell berücksichtigt werden!
Also hast Du x mal y etwas vom Typ Feld. Wie kannst Du das abbilden? Kennst Du eine Datenstruktur, die dies erlaubt?
Und dann hast Du Felder. Ein Feld ist gekennzeichnet durch einen Typ. Und dann kann da etwas auf dem Feld sein. Da wäre dann eine Frage: Wie viele Elemente?
- 0..1? (Also kein Element oder max 1 Element?)
- 1?(Also immer genau ein Element?)
- 0..n? (also beliebig viele Elemente?)
Das kann man dann entsprechend modellieren. Das 0..1 und 1 ist fast gleich. Das wäre eine Referent die eben null sein kann oder nicht.... Und für den letzten Fall wäre die Frage: Kennst Du irgend ein Konstrukt, in das Du 0, 1 oder beliebig mehr Elemente packen könntest?
1. Es hat sich ja herausgestellt, dass man x mal y etwas vom Typ Feld durch ein 2D-Array darstellen kann. Aber das Array, was ich dort habe erfüllt glaube ich noch nicht diese Anforderung, aber wenn ja warum?
2. Um dem Typ Feld auch baits zuzuordnen, sollte ein eindimensionales Array den Zweck erfüllen. Ist das korrekt so, wie im Code?
@fhoffmann
Okay, mal angenommen ich übernehme deine Konventionen so, wie auf deinem Bild. Wie sage ich denn jetzt der Klasse Maze spezifisch das waagerechte Mauern (gerade x ungerade ist) und senkrechte Mauern (ungerade x gerade) ? Außerdem haben wir für den Player jetzt eine Instanzvariable des Typs Position erstellt. Da fällt es mir schwer zu verstehen, wie ich das unten Zitierte jetzt implementieren kann, weiß das nicht einzuordnen.
Du hast dafür verschiedene Möglichkeiten:
Die Klasse Position könnte eine Methode haben wie boolean isValidForPlayer()
Oder die Klasse Player könnte dies abfangen in der Methode void setPosition(Position position) throws IllegalArgumentException
Oder die Klasse Maze regelt das...
Okay, mal angenommen ich mache das jetzt mit deiner 2. vorgeschlagenen Möglichkeit. Konkret:
Zuerst muss ich eine doppelte (z.B. if-Schleife) implementieren, in der ersten sage ich (wenn x (=Spalte)) gerade ist (mithilfe vom Modulo), dann werfe Exception und wenn y gerade ist ebenfalls dasselbe oder ? @fhoffmann
Für Wände musst du es analog implementieren.
Ob du überhaupt "Wege" benötigst, möchte ich bezweifeln. Ein Player kann nach Norden gehen, wenn sich nördlich von ihm keine Wand befindet. Wozu dann noch "Wege" einführen?
Neben allen Diskussionen über das Klassendesign, ist es doch aus interessant, wie das Labyrint überhaupt gespeichert werden soll.
Oder anders gefragt: Was ist die "Position" einer Mauer und was ist die "Position" eines Spielers?
Auf einem karierten Blatt Papier würde ich die Mauern auf die Linien zeichnen und die Spieler in die Kästchen. Damit habe ich aber doch zwei unterschiedliche Arten von "Positionen".
@mrBrown
Wie war das nochmal mit der Instanzbildung von enums? Denn um das enum "viewDir" mit der Klasse Player zu verbinden, muss
ich ja in der Klasse Player eine Instanzvariable erzeugen von "viewDir".
Das ist eine andere und deutlich einfachere Darstellung, als die von @fhoffmann vorgeschlagene. Alles, was sich auf diese Darstellung bezogen hat, brauchst du nicht.
Keine Ahnung was du meinst. Wenn du auf einen Wert nicht zugreifen bräuchtest, bräuchtest du den Wert nicht – also ja, irgendwie ist es schon erforderlich, auf irgendwelche Werte zuzugreifen.
Nur noch kurz zurück zu der Idee, die ich aufgebracht hatte:
Die Enumeration wäre FieldType oder so. Generell ist bei einer Enumeration aus meiner Sicht darauf zu achten, dass man halt konstante Instanzen hat. Also ich vermeide immer, da irgendwas einzubauen, das veränderlich ist.
Dann gibt es eine Klasse Field. Diese Klasse hat dann z.B. eine Instanzvariable FieldType, die angibt, was für ein Feld es sein soll sowie die Baits (Also als List<Bait> oder so).
Das wäre dann der grobe Aufbau.
Dann kann man sich noch überlegen, wo welche Informationen noch hinzu kommen. FieldType könnte z.B. ein boolean enthalten, der angibt, ob ein Spieler auf so ein Feld kann. Denn das ist eine Information die aus meiner Sicht eher da hin gehören würde.
Aber das waren halt nur ein paar Ideen von meiner Seite, die jetzt ggf. schon überholt sind, da Du einen anderen Weg eingeschlagen hast oder so ...
Das ist eine andere und deutlich einfachere Darstellung, als die von @fhoffmann vorgeschlagene. Alles, was sich auf diese Darstellung bezogen hat, brauchst du nicht.
1. Okay, aber wie sage ich jetzt wo Wände sind ? Das müsste ich dann trotzdem wissen. Wie würde sich das Labyrinth bei 30;10 z.B. verändern?
2. Wie sage ich jetzt einem Feld, welche Felder der Player betreten darf? @JustNobody
Nur noch kurz zurück zu der Idee, die ich aufgebracht hatte:
Die Enumeration wäre FieldType oder so. Generell ist bei einer Enumeration aus meiner Sicht darauf zu achten, dass man halt konstante Instanzen hat. Also ich vermeide immer, da irgendwas einzubauen, das veränderlich ist.
Dann gibt es eine Klasse Field. Diese Klasse hat dann z.B. eine Instanzvariable FieldType, die angibt, was für ein Feld es sein soll sowie die Baits (Also als List<Bait> oder so).
@JustNobody Okay, also eine Enumeration <<FieldType>> und eine Klasse "Field" würden benötigt, um das so darzustellen. Ich merke schon, da steckt sehr objektorientiertes Denken drin. Ne, ich habe noch keinen anderen Weg eingeschlagen.
Ja gut, boolean PATH = true; wäre schonmal nicht richtig. Vielleicht ein Tipp noch dazu?
Dann gibt es eine Klasse Field. Diese Klasse hat dann z.B. eine Instanzvariable FieldType, die angibt, was für ein Feld es sein soll sowie die Baits (Also als List<Bait> oder so).
Nochmal hierzu: Ja, aber wie mache ich das dann, sodass die Liste dem FieldType zugeordnet werden kann, sodass das z.B. FieldType "PATH" weiß, dass nur dort Baits liegen dürfen.
Die Werte UNKNOWN, WAY, WALL stammen jetzt von mir - ich habe nicht nachgesehen, wie es richtig heißen soll. Und da kann an natürlich noch die String Representation hinzu fügen wenn man möchte ...
Und wenn Field ein FieldType hat, dann kann man da jederzeit prüfen, ob ein Spieler auf das Feld kann über das isPlayerAllowed der Enumeration.
Dann gibt es eine Klasse Field. Diese Klasse hat dann z.B. eine Instanzvariable FieldType, die angibt, was für ein Feld es sein soll sowie die Baits (Also als List<Bait> oder so).
WIe verknüpfe ich denn jetzt die Instanzvariable FieldType mit der List, sodass die List weiß, dass alle in ihr enthaltenen Baits dem FieldType PATH angehören?
WIe verknüpfe ich denn jetzt die Instanzvariable FieldType mit der List, sodass die List weiß, dass alle in ihr enthaltenen Baits dem FieldType PATH angehören?
Dann gibt es eine Klasse Field. Diese Klasse hat dann z.B. eine Instanzvariable FieldType, die angibt, was für ein Feld es sein soll sowie die Baits (Also als List<Bait> oder so).
Ja, ich habe eine Instanzvariable FieldType angelegt und diese weiß jetzt, dass sie als PATH definiert ist.
Doch wenn ich jetzt eine Liste anlege wie z.B. List<BaitType>, weil in der Enumeration BaitType die verschiedenen Baits aufgezählt sind, weiß die Instanzvariable FieldType PATH noch nicht, dass die in der Liste vorhandenen Baits dieser zuzuschreiben sind... @mrBrown
