Hey, ich brauche mal ein wenig organisatorische Hilfe bezüglich OOP.
Ich habe angefangen ein Programm zu schreiben und möchte jetzt zusammengehörende Teilbereiche in eigene Klassen zu stecken.
Jedoch habe ich hier ein Problem. Obwohl die jeweiligen Klassen von der Logik her zusammengehören, müssen sie auch mit anderen Klassen (oder halt mit den jeweiligen Instanzen der Klassen) kommunizieren.
Beispiel: Eine Gebäude Klasse muss bei Ressourcen anfragen können, ob ausreichend Rohstoffe bereitstehen und kann bei Erfolg den Gebäudeauftrag bei einer anderen Klasse in Auftrag geben.
Momentan habe ich das so gelöst, dass jeder Instanz die abhängigen Instanzen als Parameter übergeben werden und den Funktionen der Klasse über self.instanz = instanz zur Verfügung stehen. (Aufruf: instanz = Klasse(instanz_foo, instanz_bar)
Ich finde diese Lösung jedoch nicht gelungen, da es passieren kann, dass eine Klasse auf viele andere Klassen zugreifen möchte und dann alle Instanzen als Parameter übergeben werden müssen. Irgendwie ist das nicht sauber.
Habt ihr ne Idee wie ich elegant von jeder Instanz die ich in der Hauptklasse von meinen benötigten Klassen erstellt habe auf die anderen Instanzen zugreifen kann?
Ich denke, dass ich das grundlegende Konzept, beziehungsweise die Basics von OOP verstehe, nur weiß ich nicht wie ich solche Probleme löse. (Jedenfalls soweit verstanden, dass ich das Gefühl habe, das es einen besseren Weg geben muss)
Bin über jede Hilfe und jeden Vorschlag dankbar.
Struktur eines Objekt orientierten Programms
Hallo,
für mich klingt das so, als solltest du deine Aufgabenverteilung noch einmal überprüfen. Orientiere dich dabei ruhig an realen Begebenheiten (ein Gebäude baut keine Gebäude), entscheide dich im Zweifel aber lieber für die Abstraktion.
Für dein konkretes Problem - sofern ich es aus der Beschreibung erkennen kann - würde ich folgenden Ansatz wählen:
Es gibt eine Hauptklasse, entsprechend dem Hauptprogramm. Diese kennt eine Instanz, die sich um das Ressourcenmanagment kümmert. Außerdem hat sie als Attribut eine Liste aller fertigen Gebäude und als ein weiteres Attribut eine Liste von Baumeister-Objekten. Wenn jetzt ein Gebäude gebaut werden soll, erteilt die Hauptklasse dem Baumeister den Auftrag "baue mir dies und das". Der Baumeister kennt die RessourcenManagment-Instanz ebenfalls (wurde ihm bei der Initialisierung übergeben) und fragt dort erst einmal an, ob überhaupt genügend Ressourcen vorhanden sind. Ist das der Fall, wird er nach einiger Zeit ein Gebäudeobjekt zurückliefern, das die Hauptklasse dann in die Liste einreihen kann. Ansonsten liefert der Baumeister ein "False" zurück, damit die Hauptklasse weiß, daß es im Augenblick nicht möglich ist, den Auftrag auszuführen. Besser wäre sogar noch, eine Exception zu werfen, die genau mitteilt, WARUM der Auftag nicht ausgeführt werden kann.
Es gibt ein bisschen Spielraum zum variieren: Z.B. könnte der Baumeister das fertige Gebäude auch direkt mit in die Liste schreiben - dann müßte er aber natürlich die Hauptklasse oder zumindest eine Referenz auf die Gebäudeliste als Attribut haben - es ist deine Entscheidung, wie stark du die Objekte untereinander vernetzen willst. Weniger ist aber manchmal mehr. Je weniger Referenzattribute du aber einsetzen willst, um so mehr mußt du mit gutdefinierten Rückgabewerten arbeiten.
für mich klingt das so, als solltest du deine Aufgabenverteilung noch einmal überprüfen. Orientiere dich dabei ruhig an realen Begebenheiten (ein Gebäude baut keine Gebäude), entscheide dich im Zweifel aber lieber für die Abstraktion.
Für dein konkretes Problem - sofern ich es aus der Beschreibung erkennen kann - würde ich folgenden Ansatz wählen:
Es gibt eine Hauptklasse, entsprechend dem Hauptprogramm. Diese kennt eine Instanz, die sich um das Ressourcenmanagment kümmert. Außerdem hat sie als Attribut eine Liste aller fertigen Gebäude und als ein weiteres Attribut eine Liste von Baumeister-Objekten. Wenn jetzt ein Gebäude gebaut werden soll, erteilt die Hauptklasse dem Baumeister den Auftrag "baue mir dies und das". Der Baumeister kennt die RessourcenManagment-Instanz ebenfalls (wurde ihm bei der Initialisierung übergeben) und fragt dort erst einmal an, ob überhaupt genügend Ressourcen vorhanden sind. Ist das der Fall, wird er nach einiger Zeit ein Gebäudeobjekt zurückliefern, das die Hauptklasse dann in die Liste einreihen kann. Ansonsten liefert der Baumeister ein "False" zurück, damit die Hauptklasse weiß, daß es im Augenblick nicht möglich ist, den Auftrag auszuführen. Besser wäre sogar noch, eine Exception zu werfen, die genau mitteilt, WARUM der Auftag nicht ausgeführt werden kann.
Es gibt ein bisschen Spielraum zum variieren: Z.B. könnte der Baumeister das fertige Gebäude auch direkt mit in die Liste schreiben - dann müßte er aber natürlich die Hauptklasse oder zumindest eine Referenz auf die Gebäudeliste als Attribut haben - es ist deine Entscheidung, wie stark du die Objekte untereinander vernetzen willst. Weniger ist aber manchmal mehr. Je weniger Referenzattribute du aber einsetzen willst, um so mehr mußt du mit gutdefinierten Rückgabewerten arbeiten.
Ich sage nur Klasse != Namensraum != Modul.
Das ganze klingt nach einem Spiel, daher reagiere ich mal überhaupt ;)
Klassen sollen gemeinsame Eigenschaften und gemeinsames Verhalten von Objekten beschreiben. Nicht mehr, nicht weniger. Gebäude, Rohstoffe, Bauauftrag, das alles klingt nach Objekten. Da es davon in der Regel mehre gleichförmige gibt, es dies praktischerweise Exemplare von ebenso benannten Klassen. Die Klasse "Bauauftrag" definiert nun, wie ein Exemplar - ein konkreter Bauauftrag - aussieht, sich verhält und insbesondere interagiert. So könnte der Bauauftrag wissen, wie man Gebäude baut.
Beispiel: Es braucht 3 Gold und 2 Holz, um eine Kaserne zu bauen. Gold und Holz sind Ressourcen(arten), die Kaserne eine Gebäude(art). Das "(art)" deutet an, dass du in einem Beispiel eigentlich noch eine Metaebene hast, denn es macht Sinn, nicht nur konkrete Arten von Ressourcen zu beschreiben, sondern auch das, was alle Ressourcen gemeinsam haben. Damit meine ich keine gemeinsame Oberklasse, sondern eine Metaklasse. Ein Stack Gold wäre ein Exemplar der Klasse GoldRessource. Gleichzeitig wäre Goldressource aber ein Exemplar der Klasse RessourcenArt. Zu schwierig, vergiss das einfach wieder ;)
Dein Problem liegt IMHO in der Interaktion der Objekte. Wenn du überlegt, was die Objekte sind (und wie man sie klassifizieren kann), denke immer in Verhaltensmuster. So könnte eine Mine (Gebäude) Gold (Ressource) produzieren. Ein Bauauftrag verbaucht Gold und erzeugt Gebäude. Dies ist die Interaktion und darüber stehen die Exemplare dann in Beziehung zueinander.
Stefan
Das ganze klingt nach einem Spiel, daher reagiere ich mal überhaupt ;)
Klassen sollen gemeinsame Eigenschaften und gemeinsames Verhalten von Objekten beschreiben. Nicht mehr, nicht weniger. Gebäude, Rohstoffe, Bauauftrag, das alles klingt nach Objekten. Da es davon in der Regel mehre gleichförmige gibt, es dies praktischerweise Exemplare von ebenso benannten Klassen. Die Klasse "Bauauftrag" definiert nun, wie ein Exemplar - ein konkreter Bauauftrag - aussieht, sich verhält und insbesondere interagiert. So könnte der Bauauftrag wissen, wie man Gebäude baut.
Beispiel: Es braucht 3 Gold und 2 Holz, um eine Kaserne zu bauen. Gold und Holz sind Ressourcen(arten), die Kaserne eine Gebäude(art). Das "(art)" deutet an, dass du in einem Beispiel eigentlich noch eine Metaebene hast, denn es macht Sinn, nicht nur konkrete Arten von Ressourcen zu beschreiben, sondern auch das, was alle Ressourcen gemeinsam haben. Damit meine ich keine gemeinsame Oberklasse, sondern eine Metaklasse. Ein Stack Gold wäre ein Exemplar der Klasse GoldRessource. Gleichzeitig wäre Goldressource aber ein Exemplar der Klasse RessourcenArt. Zu schwierig, vergiss das einfach wieder ;)
Dein Problem liegt IMHO in der Interaktion der Objekte. Wenn du überlegt, was die Objekte sind (und wie man sie klassifizieren kann), denke immer in Verhaltensmuster. So könnte eine Mine (Gebäude) Gold (Ressource) produzieren. Ein Bauauftrag verbaucht Gold und erzeugt Gebäude. Dies ist die Interaktion und darüber stehen die Exemplare dann in Beziehung zueinander.
Stefan