Können Manager-Klassen ein Zeichen für schlechte Architektur sein?

In letzter Zeit habe ich angefangen zu denken, dass es eine schlechte Sache ist, viele Manager-Klassen in Ihrem Design zu haben. Die Idee ist noch nicht so ausgereift, dass ich ein überzeugendes Argument vorbringen könnte, aber hier sind einige allgemeine Punkte:

• Ich fand es viel schwieriger für mich, Systeme zu verstehen, die stark von "Managern" abhängen. Dies liegt daran, dass Sie neben den eigentlichen Programmkomponenten auch verstehen müssen, wie und warum der Manager verwendet wird.

• Manager scheinen die meiste Zeit verwendet zu werden, um ein Problem mit dem Design zu lindern, zum Beispiel, wenn der Programmierer keine Möglichkeit gefunden hat, das Programm Just Work ^TM zu erstellen, und sich auf Manager-Klassen verlassen musste, damit alles richtig funktioniert.

Natürlich können Krippen gut sein. Ein naheliegendes Beispiel ist eines EventManagermeiner Lieblingskonstrukte aller Zeiten. : P Mein Punkt ist, dass Manager häufig überlastet zu sein scheinen und aus keinem anderen Grund als ein Problem mit der Programmarchitektur zu verschleiern.

Sind Manager-Klassen wirklich ein Zeichen für schlechte Architektur?

Manager-Klassen können aus folgenden Gründen ein Zeichen für eine schlechte Architektur sein:

• Bedeutungslose Bezeichner

  Der Name FooManagersagt nichts darüber aus, was die Klasse tatsächlich tut , außer dass es sich irgendwie um FooInstanzen handelt. Wenn Sie der Klasse einen aussagekräftigeren Namen geben, erfahren Sie mehr über ihren wahren Zweck, der wahrscheinlich zu Umgestaltungen führen wird.

• Fractional Responsabilities

  Nach dem Prinzip der Einzelverantwortung sollte jede Codeeinheit genau einem Zweck dienen. Mit einem Manager können Sie diese Verantwortung künstlich aufteilen.

  Stellen Sie sich vor ResourceManager, Sie koordinieren die Lebensdauer und den Zugriff auf ResourceInstanzen. Eine Anwendung verfügt über eine einzige Instanz, ResourceManagerüber die sie ResourceInstanzen abruft . In diesem Fall gibt es keinen wirklichen Grund, warum die Funktion einer ResourceManagerInstanz nicht von statischen Methoden in der ResourceKlasse bedient werden kann.

• Unstrukturierte Abstraktion

  Häufig wird ein Manager eingeführt, um zugrunde liegende Probleme mit den von ihm verwalteten Objekten zu beseitigen. Aus diesem Grund neigen Manager dazu, sie als Pflaster für schlecht konzipierte Systeme zu missbrauchen. Abstraktion ist ein guter Weg, um ein komplexes System zu vereinfachen, aber der Name „Manager“ gibt keinen Hinweis auf die Struktur der Abstraktion, die es darstellt. Ist es wirklich eine Fabrik oder ein Proxy oder etwas anderes?

Natürlich können Manager aus den gleichen Gründen für mehr als nur das Böse eingesetzt werden. Ein EventManager- was wirklich ein - Dispatcherstellt Ereignisse aus Quellen in eine Warteschlange und sendet sie an interessierte Ziele. In diesem Fall ist es sinnvoll, die Verantwortung für das Empfangen und Senden von Ereignissen zu trennen, da es sich bei einer Person Eventlediglich um eine Nachricht ohne Herkunfts- oder Zielangabe handelt.

Wir schreiben eine Dispatchervon EventInstanzen aus im Wesentlichen demselben Grund, aus dem wir eine GarbageCollectoroder eine schreiben Factory:

Ein Manager weiß, was seine Nutzlast nicht wissen muss.

Das ist meiner Meinung nach die beste Rechtfertigung für die Schaffung einer managerähnlichen Klasse. Wenn Sie ein "Nutzlast" -Objekt haben, das sich wie ein Wert verhält, sollte es so dumm wie möglich sein, damit das Gesamtsystem flexibel bleibt. Um einzelnen Instanzen eine Bedeutung zu verleihen, erstellen Sie einen Manager, der diese Instanzen auf sinnvolle Weise koordiniert . In allen anderen Situationen sind Manager nicht erforderlich.

Manager können ein Zeichen für eine schlechte Architektur sein, aber in den meisten Fällen sind sie nur ein Zeichen für die Unfähigkeit des Designers, bessere Namen für seine Objekte zu finden, oder einfach nur ein Spiegelbild der Tatsache, dass die englische Sprache (und jede menschliche Sprache in dieser Angelegenheit) ist geeignet, um alltägliche praktische Konzepte zu kommunizieren, und nicht hoch abstrakte, hoch technische Konzepte.

Ein einfaches Beispiel, um meinen Standpunkt zu veranschaulichen: Bevor das Factory-Pattern benannt wurde, verwendeten die Leute es, aber sie wussten nicht, wie sie es nennen sollten. Jemand, der eine Fabrik für seine FooKlasse schreiben musste, hat sie vielleicht genannt FooAllocationManager. Das ist kein schlechtes Design, das ist nur ein Mangel an Vorstellungskraft.

Und dann muss jemand eine Klasse implementieren, die viele Fabriken unterhält und sie an verschiedene Objekte verteilt, die nach ihnen fragen. und er ruft seine Klasse an, FactoryManagerweil ihm das Wort Industryeinfach nie in den Sinn gekommen ist, oder er dachte, es wäre uncool, weil er noch nie zuvor von so etwas in der Programmierung gehört hat. Wieder ein Fall von mangelnder Vorstellungskraft.

Viele "Manager" -Klassen zu haben, ist oft ein Symbol für ein anämisches Domänenmodell , bei dem die Domänenlogik aus dem Domänenmodell herausgehoben und stattdessen in Manager-Klassen eingeordnet wird , die mehr oder weniger Transaktionsskripten entsprechen . Die Gefahr besteht darin, dass Sie im Grunde auf die prozedurale Programmierung zurückgreifen - dies kann je nach Projekt an sich eine gute Sache sein oder auch nicht -, aber die Tatsache, dass dies nicht in Betracht gezogen oder beabsichtigt wurde, ist das eigentliche Problem.

Nach dem Prinzip des "Informationsexperten" sollte eine logische Operation so nah wie möglich an den Daten liegen, die sie benötigt. Dies würde bedeuten, dass die Domänenlogik wieder in das Domänenmodell verschoben wird, sodass sich diese logischen Operationen spürbar auf den Status des Domänenmodells auswirken, anstatt dass „Manager“ den Status des Domänenmodells von außen ändern.

Kurze Antwort: es kommt darauf an .

Es gibt verschiedene Arten von "Managerklassen", einige davon sind gut, andere schlecht, und für die meisten von ihnen hängt es stark vom Kontext ab, ob die Einführung einer Managerklasse das Richtige ist. Ein guter Ausgangspunkt, um sie in Ordnung zu bringen, ist die Befolgung des Grundsatzes der einheitlichen Verantwortung. Wenn Sie genau wissen, wofür jede Ihrer Managerklassen verantwortlich ist (und wofür nicht), haben Sie weitaus weniger Probleme, sie zu verstehen.

Oder um Ihre Frage direkt zu beantworten: Es ist nicht die Anzahl der Manager-Klassen, die auf eine schlechte Architektur hinweisen, sondern zu viele mit unklaren Verantwortlichkeiten oder zu vielen Bedenken.

Man kann leicht sagen, dass sie von Natur aus auf ein schlechtes Design hindeuten, aber sie können dazu beitragen, viel Gutes zu bringen und die Codekomplexität und anderen Code während des gesamten Projekts zu reduzieren, indem sie eine einzige Aufgabe und Verantwortung universell umfassen.

Während die Prävalenz von Managern auf eine schlechte Beurteilung des Designs zurückzuführen sein kann, kann es auch sein, dass sie schlechte Designentscheidungen oder Inkompatibilitätsprobleme mit anderen Komponenten in einem komponentenbasierten Design, mit UI-Komponenten von Drittanbietern oder mit Webservices von Drittanbietern mit einer seltsamen Benutzeroberfläche behandeln als Beispiele.

Diese Beispiele zeigen, wo sie in bestimmten Situationen für die Reduzierung der Gesamtkomplexität und die Förderung der losen Kopplung zwischen verschiedenen Komponenten und Schichten von großem Nutzen sind, indem der "hässliche Code" an einer einzigen Stelle gekapselt wird. Ein Problem wäre jedoch, dass die Leute es verlockend finden, Manager als Singletons zu ernennen. Ich würde davon abraten, und natürlich, da andere vorgeschlagen haben, dass das Prinzip der Einzelverantwortung immer befolgt werden sollte.

Können Manager-Klassen ein Zeichen für schlechte Architektur sein?

Sie haben Ihre Frage beantwortet: Sie müssen kein Zeichen für ein schlechtes Design sein.

Abgesehen von dem Beispiel in Ihrer Frage mit dem EventManager gibt es ein anderes Beispiel: Im MVC- Entwurfsmuster kann der Präsentator als Manager für die Modell- / Ansichtsklassen angesehen werden.

Wenn Sie jedoch ein Konzept missbrauchen, ist dies ein Zeichen für ein schlechtes Design und möglicherweise für eine schlechte Architektur.

Wenn die Klasse „Manager“ im Namen hat, passen sie von dem Gott Klasse Problem (ein mit zu vielen Aufgaben). Wenn es schwierig ist zu beschreiben, wofür eine Klasse mit ihrem Namen verantwortlich ist, ist dies ein Design-Warnzeichen.

Abgesehen von schlechten Manager-Klassen war der schlechteste Name, den ich je gesehen habe, "DataContainerAdapter".

"Daten" sollte eine andere dieser verbotenen Teilzeichenfolgen in Namen sein - es sind alles Daten, "Daten" sagt in den meisten Domänen nicht viel aus.

Manager-Klassen sind - wie fast jede Klasse, die mit "-er" endet - böse und haben nichts mit OOP zu tun. Für mich ist das ein Zeichen für schlechte Architektur.

Warum? Der Name "-er" impliziert, dass ein Code-Designer eine Aktion ausgeführt und diese in eine Klasse konvertiert hat. Als Ergebnis haben wir eine künstliche Entität, die kein konkretes Konzept widerspiegelt, sondern eine Aktion. Das klingt sehr prozedural.

Außerdem nehmen solche Klassen normalerweise einige Daten und verarbeiten sie. Dies ist eine Philosophie von passiven Daten und aktiven Prozeduren , die ihren Platz in der prozeduralen Programmierung gefunden hat. Wenn Sie das bemerken, gibt es nichts Schlechtes in Manager-Klassen, aber es ist dann nicht OOP.

Objektdenken impliziert, dass Objekte sich selbst etwas antun. Entdecken Sie Ihre Domäne , bauen Sie semantische Netze , lassen Sie Ihre Objekte lebende Organismen, intelligente und verantwortungsbewusste Menschen sein.

Solche Objekte müssen nicht kontrolliert werden. Sie wissen, was zu tun ist und wie zu tun ist. Manager-Klassen brechen also zweimal die OOP-Prinzipien. Es ist nicht nur eine "-er" -Klasse, sondern steuert auch andere Objekte. Aber es hängt vom Manager ab. Er kontrolliert es - er ist ein schlechter Manager. Wenn er koordiniert - er ist ein guter Manager. Aus diesem Grund sollte ein "C" -Buchstabe in MVC als "Koordinator" geschrieben werden.

Die richtige Antwort auf diese Frage lautet:

1. Es hängt davon ab, ob.

Jede Situation beim Schreiben der Software ist anders. Vielleicht sind Sie in einem Team, in dem jeder weiß, wie Manager-Klassen intern arbeiten? Es wäre völlig verrückt, dieses Design nicht zu verwenden. Oder wenn Sie versuchen, das Manager-Design auf andere zu übertragen, ist dies möglicherweise eine schlechte Idee. Aber es kommt auf genaue Details an.