OOP Klassen-Design (static oder nicht?)

Leifa

Mitglied
Hallo,

ich arbeite zur Zeit an einem kleinen Projekt, habe jetzt etwa 20 Klassen und mir stellen sich einige Fragen zum Design der Klassen. Gelöst kriege ich meine Probleme zwar, aber ich frage mich immer, ob diese Lösungen richtig oder schön sind, oder ob es in der Praxis anders gemacht wird.

Ich habe 2 Klassen mit einem Sonderstatus, nämlich Programm und Settings.

  • Code:
    Programm
    ist bei mir die zentrale Klasse, welche Methoden besitzt, welche später vom UI genutzt werden. Ich erzeuge hiervon nur ein Objekt.
  • Code:
    Settings
    ist eine Klasse, in der verschiedene Parameter gespeichert sind. Diese soll der User später auch verändern dürfen.

Settings habe ich als Singleton implementiert, da ja nur eine Instanz gebraucht wird. Ich frage mich jetzt, wie der Zugriff auf die Settings erfolgen sollte. Hier einige Vorschläge:

  • Der User könnte auf die Setting-Instanz direkt zugreifen. Doch wie erfährt dann das Programm davon, dass die Settings geändert wurden? Die Klasse Settings sollte eigentlich gar nicht wissen, dass es die Klasse Programm gibt.
  • Das Programm könnte für jede Einstellung in den Settings eigene Getter- und Setter-Methoden bereitstellen, und Zugriffe auf die Settings laufen nur hierüber? Das wären sehr viele Methoden, die meinem Gefühl nach nicht in die Klasse Programm gehören.
  • Der User könnte über das Programm eine Kopie des Setting-Objekts bekommen und daran dann Änderungen vornehmen. Das geänderte Objekt gibt er dem Programm zurück und dieses gibt der Klasse Settings das neue Objekt weiter und vermerkt, dass die Einstellungen geändert wurden.

Letzere Möglichkeit erscheint mir noch am logischsten, wobei ich gerne mal hören würde, wie soetwas allgemein gelöst wird. Ich hoffe es war verständlich und jemand weiß mir zu helfen.

Gruß
Leif
 
Hallo.

Ich würde hier das Observer-Pattern realisieren.

siehe Beobachter (Entwurfsmuster) ? Wikipedia

Auf dein Problem angewendet bedeutet das, dass Settings das Subjekt ist auf das sich beliebig viele Beobachter registrieren können. Beobachter wäre demzufolge also das Progamm.

Ein wichtiger Vorteil wäre dass sich bei Bedarf noch weitere Beobachter bei Settings registrieren können die bei Änderungen in Settings ebenfalls informiert werden.


Rainer
 
  • Code:
    Settings
    ist eine Klasse, in der verschiedene Parameter gespeichert sind. Diese soll der User später auch verändern dürfen.

Settings habe ich als Singleton implementiert, da ja nur eine Instanz gebraucht wird. Ich frage mich jetzt, wie der Zugriff auf die Settings erfolgen sollte. Hier einige Vorschläge:

  • Der User könnte auf die Setting-Instanz direkt zugreifen. Doch wie erfährt dann das Programm davon, dass die Settings geändert wurden? Die Klasse Settings sollte eigentlich gar nicht wissen, dass es die Klasse Programm gibt.
  • Das Programm könnte für jede Einstellung in den Settings eigene Getter- und Setter-Methoden bereitstellen, und Zugriffe auf die Settings laufen nur hierüber? Das wären sehr viele Methoden, die meinem Gefühl nach nicht in die Klasse Programm gehören.
Dass die Getter und Setter nicht in die Programm-Klasse gehören stimmt wohl, aber was spricht gegen Getter und Setter in der Setting-Klasse, gerade wenn sie als Singleton implementiert ist? Oder habe ich jetzt irgendwas nicht ganz verstanden?
 
Bei nur zwei Klassen würde ich kein Beobachter Muster machen.
Gib der Settings Klasse einen Konstruktor die ein Programm Objekt erwartet.
Wenn du dann das Settings Frame aus dem Programm öffnest, dann: Settings s = new Settings(this);

Über dieses Objekt kann deine Settings Klasse das Programm direkt ändern und die getter / setter in der Programm Klasse nutzen 🙂

Und "geänderte" Objekte übergeben gibt es in Java nicht.
Methoden Parameter werden übergeben:

- Bei primitiven Typen (int, double usw.) als Kopie, d.h. änderst was daran in der Methode, ändert es nix am original !

- Anders bei Objekten, die werden als Referenz übergeben, d.h. eine Speicherstelle. Egal wo du daran etwas änderst, es ändert auch das Original. So kann die Settings mit dem obigen Vorschlag das eigentliche Programm manipulieren.
 
Zuletzt bearbeitet:

Zurück
Oben