Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

helebelele

Frischling

  • »helebelele« ist der Autor dieses Themas

Beiträge: 32

Wohnort: Düsseldorf

  • Private Nachricht senden

1

02.02.2012, 12:53

Klasse als Parameter übergeben sinnvoll?

Hallo,

ich habe bei meinem Programm ein kleines Problem.
Ich arbeite grad an einem kleinen Spiel, das bisher noch in der Konsole läuft. Dabei habe ich eine Klasse für das Hauptmenü. Wenn ich ein neues Spiel starte wird dort eine Instanz der Klasse Player für den neuen Spieler angelegt.
Danach soll man in einer Stadt sein, in der man verschiedene Möglichkeiten hat, was man machen will. Dafür brauch ich natürlich auch die Informationen des Spielers, falls er auf die Jagd geht oder in einem Laden etwas kauft.

Ich habe mir das jetzt so gedacht:
1. Ich habe eine Instanz der Klasse des Menüs erstellt, damit das läuft.
2. Die Klasse Menu hat die Klasse Player included um den Spieler zu erstellen.
3. Danach wird eine Instanz der Klasse Town erstellt.

Jetzt habe ich mir gedacht, dass ich ja die Instanz vom Spieler in der Klasse Menu erstellt habe. Reicht es dann, wenn ich die Klasse Player einfach in der Klasse Town include oder muss ich besser beim erstellen der Stadt im Konstruktor die Instanz des Spielers übergeben?

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

2

02.02.2012, 13:11

Naja du willst ja in der Klasse Town die selbe Instanz nutzen wie im Menü oder nicht. Von daher musst du sie der Townklasse irgendwie geben. Da gäbe es jetzt viele Möglichkeiten. Du kannst die Klasse einfach als Parameter übergeben. Ich würde vermutlich eine Ebene drüber anfangen. In Main oder der darüber liegenden Klasse würde ich den Spieler erstellen. Diesen könnte man dann an das Menü, die Town und alle anderen Klassen weiterreichen. Menü und Town könnten dann einen Zeiger auf den Spieler direkt im Konstruktor bekommen. Da gibts natürlich auch andere Möglichkeiten aber so würde es zum Beispiel funktionieren.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

helebelele

Frischling

  • »helebelele« ist der Autor dieses Themas

Beiträge: 32

Wohnort: Düsseldorf

  • Private Nachricht senden

3

02.02.2012, 13:17

Ich habe mir jetzt was überlegt.
Da es ja ein RPG werden soll, müssen die Daten vom Spieler ja irgendwo gespeichert werden(irgendwann mach ich das XD).
Demnach hab ich jetzt der Klasse Town 2 Funktionen gegeben. Die erste wird ausgeführt wenn ein neues Spiel gestartet wird. Dann wird dabei der Spieler erstellt. Die zweiter ist zum fortsetzen falls man schon einen
Spielstand haben sollte. Da wird der Spieler dann einfach aus einer Datei ausgelesen. Wenn ich das so mache ist die Klasse Menu überflüssig und kann mir so einiges an Quellcode sparen :)
So würde das doch bestimmt auch gehen oder nich?

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

4

02.02.2012, 15:24

Funktionieren würde das. Es gibt natürlich wie immer schönere Lösungen aber mach es ruhig so:)
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

5

02.02.2012, 22:20

Mein Tipp: Probiere es einfach aus. Bei Design Fragen geht es zu großen Teilen um Erfahrung.

Programmiere einfach ein wenig drauf los und schau dir dann an, wie dein Code aussieht. Abhängigkeiten sollten möglichst klein gehalten werden, Daten so lokal sein wie möglich und Klassen wiederverwendbar. Klassen und Funktionen sollten nur das tun, was ihr Name vermuten lässt, ich weiß zum Beispiel nicht, was ein (Haupt)menü mit dem Spielerobjekt zu tun hat? Wofür braucht man das da? Wenn deine Townklasse die Spielwelt verwaltet, ist der Spieler dort gut aufgehoben. Wenn es eine übergeordnete Game Klasse gibt, ist er dort vielleicht besser.
Aber das sind nur generelle Hinweise, warum die Sinn machen, lernst du am ehesten durch ausprobieren. Also, immer kritisch das Codedesign hinterfragen.
Lieber dumm fragen, als dumm bleiben!

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

6

02.02.2012, 22:57

Über die Wiederverwendbarkeit von Code lässt sich aber auch streiten. In den meisten Fällen wird man seinen Code nicht noch mal verwenden. Dann kann man sich eine Menge arbeit sparen, wenn man Code nicht unnötig aufbläht um ihn wiederverwendbar zu machen. Manchmal ist es auch gut Code einfach so zu schreiben wie er gebraucht wird. Ich wollte jetzt damit keine Grundsatzdiskussion losreißen. Ich stimme selbst auch zu, dass man Code möglichst wiederverwendbar gestallten sollte, aber man kanns halt auch damit übertreiben;) Vor allem am Anfang sollte erst mal das Ziel an erster Stelle stehen.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

7

02.02.2012, 23:22

Ja, guter Punkt. Ein Beispiel dass ich neulich dazu gehört habe, ist das erstellen von Objekten. Man könnte eine Factoryklasse programmieren, oder einfach ein switch mit 3 verschiedenen Zweigen. Die switch-Lösung ist wesentlich kompakter (~8 Zeilen statt 50-100?), und in einfachen Fällen auch besser (alleine da man sich die zusätzlichen Dateien für die Factory spart) aber sobald man das an merheren Stellenb raucht, oder auf einfache Weise neue KLassen registreiren will (vielelicht sogar zur Laufzeit), ist die Factory natürlich besser.
Aber wie gesagt, das macht die Erfahrung. Bei manchen Stellen weiß man vielleicht schon, dass sich dort nie wieder etwas ändern wird, da wäre erweiterbares Codedesign vielleicht umständlicher als eine 'straight-forward'-Lösung. Irgendwann kann man sowas halt abschätzen.
Lieber dumm fragen, als dumm bleiben!

Werbeanzeige