Definitionsfrage: Objektklassen <-> Managerklassen

[GU4RDI4N]

hi,
ich hab da mal eine reine definitionsfrage die nur auf reinem interresse beruht:

Normalerweise sind Klassen/Instanzen eher wie Objekte gedacht.
Das heisst ich erstelle eine Klasse "Auto" (*g*) und leite davon
mehrere Instanzen ab, wovon jede Instanz ein eigenes Auto für sich darstellt.
Will man auf ein Auto zugreifen und z.B.: seine Farbe ändern,
braucht man dafür die Instanz dieses Autos und wendet auf diese Instanz dann
z.B.: die Methode ändereFarbe("blau"); an.
So hab ich es in der Schule gelernt.

Nun treffe ich aber immer häufiger auf diese "Managerklassen". (ist das ein passendes Wort dafür?)
Diese scheinen dem oben genannten (und wohl bekannten) Konzept der abstrakten Objekte zu wiedersprechen.
Die funktionieren meistens so dass man ganz am Anfang eine einzige Instanz von ihnen erstellt und mit dieser
dann auf alle Objekte zugreifen kann.
So erstelle ich zum Beispiel eine Klasse AutoManager, welche z.B.: die Methoden
"int erstelleAuto(string Farbe, int PS, string Hersteller);",
"bool ändereAuto(int AutoID, string Farbe, int PS, string Hersteller);",
"bool löscheAuto(int AutoID);" und
"int[] listeAlleAutos();" hat,
mit welcher man auf sämtliche Auto's zugreifen kann, ohne Instanziieren zu müssen,
oft sogar komplett ohne Objekte arbeiten, sondern nur mit Strings, Integer-Werten, etc... .

Und dann gibt es natürlich noch Mischformen die alle Autos listen,
bearbeiten, erstellen, löschen, etc... kann,
aber auch instanzen der Autos selbst zurückgeben kann,
aber so etwas scheint ziemlich selten zu sein.


Wiederspricht letzteres dem Konzept von OOP?

Sollte man so etwas vermeiden?

Hat es vielleicht sogar irgendwelche Nachteile/Vorteile?

Ist das Programmiersprachenabhängig?
(bin hauptsächlich PHP-Programmierer)

Wie ist eure Meinung dazu?


(Und haben diese "Managerklassen" bereits einen Namen den ich nur nicht kenne?)

(Sry falls gleich bei Google der erste Treffer die Antwort gewesen wäre,
aber ich habe unter den Stichpunkten die ich benutzt habe nichts gefunden.)



MfG
GU4RDI4N

[BlueJay]

Meinst du so was wie eine Fabrik?

so long,
BlueJay

[GU4RDI4N]

nein, ähm...

angenommen man hat eine ( physikalische *g* ) Fabrik mit mehreren Maschinen und will diese über ein Objektorientiertes Programm steuern.
Nach dem OOP-Prinzip würde man hier eine Klasse "Maschine" anlegen
die genau eine einzige Maschine in der Fabrik steuert.
Jede Maschine wäre durch genau eine Instanz dieser Klasse repräsentiert.

Wenn man eine Managerklasse dafür nimmt,
würde man die Klasse "MaschinenManager" schreiben und es würde nur eine einzige Instanz dieser Klasse während des gesamten Laufzeit existoeren.
Dann müsste man jeder Maschine eine eindeutige ID (meistens integer) zuweisen.
Die Methoden zum steuern der Maschinen sind alle in der Manager-Klasse,
und um die zu steuernde Maschine zu wählen übergibt man die ID mit als Parameter zu dieser Methode.


Also statt dem normalen OOP-Weg...

...
maschine_A = new Maschine(1); // hole Maschine mit ID 1 als "maschine_A"
maschine_B = new Maschine(2); // hole Maschine mit ID 2 als "maschine_B"
maschine_C = new Maschine(3); // hole Maschine mit ID 3 als "maschine_C"

maschine_A.starte(); // starte Maschine mit ID 1
maschine_B.starte(); // starte Maschine mit ID 2
maschine_C.starte(); // starte Maschine mit ID 3
...

maschine_B.schneller(5); // beschleunige Maschine mit ID 2 um 5
...

...schreibt man etwas in die Richtung:

...
maschinen = new MaschinenManager();

maschinen_manager.starte(1); // starte Maschine mit ID 1
maschinen_manager.starte(2); // starte Maschine mit ID 2
maschinen_manager.starte(3); // starte Maschine mit ID 3
...
maschinen_manager.schneller(2, 5); // beschleunige Maschine mit ID 2 um 5
...

Das dieser Weg dem eigentlichen Sinn des OOP etwas entgegensteht weiss ich selbst,
doch trotzdem sehe ich solche Konstrukte immer häufiger.

Oft sind diese Manager dann auch so gebaut das sie Global verfügbar sind.
(z.B.: über einen "Obermanager" (Factory?), welcher Referenzen auf alle anderen Manager enthält und an jede Klasse weitergereicht wird.)

Ein Vorteil den ich mir vorstellen könnte wäre es das man nicht mehr irgendwo Instanzen herumfliegen hat die beim Programmieren nicht beachtet werden sondern alles was zusammen gehört an einer Stelle hat.


MfG
GU4RDI4N

[anda_skoa]

Das Konzept ist nicht unbedingt schlecht, es hängt halt stark davon ab, wie es umgesetzt ist.

Wenn wir das Beispiel mit den Maschinen nehmen, ist es sehr wahrscheinlich, dass man die Maschinen nicht immer in einzelnen Variablen halten möchte, sondern in einem Container.

Wenn die Maschinen völlig unabhängig sind, reicht vermutlich ein Standardcontainer, z.B. eine Map.

Aber wenn man sich mal die Situations einer Fertigungsstraße ansieht, möchte man vielleicht sicherstellen, dass das Abschalten einer Maschine auch alle davor abschaltet, usw.

So eine Klasse würde man dann vielleicht FertigungsstrassenKontrolle nennen, oder eben MaschinenManager.

Ob so eine Klasse dann die untergeordneten Einheiten auch erzeugen sollte, ist wieder eine andere Frage. Auch hier könnte die Sicherstellung von Zusammenhängen es nötig machen, z.B. beim Erzeugen einer Maschine des Typs A immer auch eine des Typs B zu erzeugen.

Während in der Realität solche Sachen über Vorschriften oder Anleitungen geregelt werden, will man in Software oft nicht, dass der benutzende Entwickler über diese Interna Bescheid wissen muss (kann, aber nicht muss. soll sich auf seine Aufgaben darüber konzentrieren können).

Natürlich kommt es auch zu ähnlichen Umsetzungen aus Gründen der Bequemlichkeit, was nicht immer falsch ist, aber vorallem bei Bibliotheken zu Schwierigkeiten führen kann, wenn damit die möglichen Einsatzszenarien eingeschränkt oder kompliziert gemacht werden.

Ciao,
_