Manager Klassen

Hallo ihr lieben Leute,
mal eine Frage von einem Anfänger.

Bei mir ist es schon häufiger vorgekommen, dass ich beim Entwerfen eines Programmes auf das Prinzip einer oder gar mehrerer Manager-Klassen zurückgegriffen habe, also Klassen, die quasi den Gesamtablauf eines Programmes gesteuert haben. Häufig ist es so, dass diese Klasse Teile der OOP-Prinzipien verletzen oder aber sie mir einfach nicht sauber programmiert vorkommen.
Daher mal die Frage, ob man dieses Vorgehen auch umgehen kann? Gibt es da Prinzipien nach denen man sich richten kann?

Ich habe auch mal ein Buch gefunden, dass versucht einem diesen Gebrauch von Manager-Klassen abzugewöhnen, da sie schlicht nicht sauber sind, dummerweise habe ich das Buch nicht gekauft und weiß auch nicht mehr welches das war. Auch habe ich kein konkretes Beispiel, hoffe aber dennoch dass ihr wißt was ich meine . sorry falls der thread etwas abstrakt ist

Gruß
der Ultra_Manager

groovemaster

Unter "Manager Klasse" kann ziemlich vieles fallen. Ohne konkrete Anwendung kann man da schwer Tipps geben. Und von den "Prinzipien", die du erwähnst, ja die gibt es. Man spricht hier von "Design Patterns". Da gibt es für praktisch jedes Szenario etwas. Für deinen Fall könnte uU das State Pattern etwas sein. Aber auch die anderen solltest du dir mal anschauen.

Eine gute Übersicht findest du hier.

yeah, schon mal danke!

mmh, also falls es nicht ohne konkretes beispiel geht, mir würde da aus meinen einstiegstagen etwas einfallen. und zwar habe ich da ein pong nachgebaut, und hatte dann eine GameManager klasse, die halt alles zusammengeführt hat, also die "flug"bahnen des balls, die bewegung der Balken, nen RenderManager zum Render der Objekte hatte die GameManager Klasse auch drin etc.... ich glaube so ne art von klassen werden auch öfter gott-klassen o.ä. genannt, denke es sollte nun etwas klarer sein was ich meine..

DEvent

Ultra_Manager schrieb:

yeah, schon mal danke!

mmh, also falls es nicht ohne konkretes beispiel geht, mir würde da aus meinen einstiegstagen etwas einfallen. und zwar habe ich da ein pong nachgebaut, und hatte dann eine GameManager klasse, die halt alles zusammengeführt hat, also die "flug"bahnen des balls, die bewegung der Balken, nen RenderManager zum Render der Objekte hatte die GameManager Klasse auch drin etc.... ich glaube so ne art von klassen werden auch öfter gott-klassen o.ä. genannt, denke es sollte nun etwas klarer sein was ich meine..

Also eine Klasse die alles organisiert gibt es sowieso. Aber die einzelnen Objekte sollten schon das können, was sie können müssen. Z.B.:

abstract class Object
{
    private position;

    public getPosition() { return position; }
    public abstract void render(Screen);
    public abstract void berechnen();
}

class Ball extends Object
{
    public void render(Screen);
    public void berechnen();
}

class Schläger extends Object
{
    public void render(Screen);
    public void berechnen();
}

class Game
{
    private List objecte;

    public void render(Screen)
    {
         forall object in objecte 
             object.berechnen();
             object.render(screen);
    }
}

Die Manager-Klasse delegiert dann die Aufgaben an die einzelnen Objekte und sie zeichnen sich z.B. selbst auf dem Monitor.

ja, genau so wars bei mir bisher immer. nun aber die frage ob man da auch drum rumkommt. ich habe halt schon öfter gehört dass das nicht sauber und etwas ungewöhnlich ist, bzw es andere techniken und ansätze gibt. falls da einer was zu weiß wär ich dankbar.

byto

Also prinzipiell wüsste ich nicht, was daran "unsauber" sein sollte. Es gibt einfach sehr häufig übergeordnete Aufgaben, die müssen ja irgendwo hin. Ich finds grundsätzlich "sauber", wenn etwaige Manager Klassen existieren mit einer Schnittstelle, um ein bestimmtes Teilsystem darüber zu steuern. Zumal Du andere Teilsysteme dann einfach über die Manager-Klasse darauf zugreifen können, ohne sonstige Details zu kennen (siehe Facade Pattern).