In meiner App habe ich ein Controller
, das von der Hauptmethode gestartet wurde. Der Controller initialisiert Hooks, Datenbankverbindungen, die Benutzeroberfläche, eine andere Verbindung und andere Dinge. Es hält den größten Teil des Programmstatus (nein, es ist kein Singleton). In einem anderen Beispiel gibt es einen Controller für den Bot, der das Interpretieren und Senden von Befehlen behandelt. Beide sind ziemlich große Dateien.
Ich habe etwas über Gott-Objekte gelesen, aber ich weiß nicht wirklich, wie ich es aufteilen könnte. Wenn ich den Interpreter und den Dispatcher im Bot aufspalte, wird es eine schreckliche Aufrufkette bilden (so etwas wie getBot().getParser().getOutput().sendMessage(recipient, message)
). In ähnlicher Weise gibt es im ersten Controller, wenn ich Dinge aufteilen würde Sie nur Datenobjekte, die Felder und einige Alias-Hilfsmethoden halten. Wenn man sie aufteilt, würde das alles noch schlimmer machen. Und bevor du davon ausgehst, dass es nicht zu halten ist, ist es das nicht. Ich habe nicht einmal den Bot-Controller geschrieben, aber ich weiß immer noch, was los ist.
Das Problem ist jedoch, dass die Bot-Klasse 2000 Zeilen lang ist (wahrscheinlich kürzer, wenn ich die Javadoc-Kommentare herausgenommen habe) und der Bot ungefähr 1000 Zeilen lang ist. Viele Zeilen = Gott Objekt. Aber ist es in Ordnung für ein oder zwei Kernklassen eines Projekts?
"Viele Zeilen" bedeutet nicht, dass die Klasse überhaupt ein Gott-Objekt ist, das ist ein schrecklicher schrecklicher Maßstab, um herauszufinden, ob Sie etwas umgestalten sollten oder nicht. Manche Dinge sind sehr kompliziert und rechtfertigen ein kompliziertes und von Natur aus großes Objekt. Die Idee eines Gottesobjekts ist das, was die Klasse macht .
Zum Beispiel, wenn ich ein Objekt gemacht habe, das könnte
%Vor%Das Objekt würde sich als ein Gott-Objekt qualifizieren, auch wenn es nur 100 Zeilen Code sein könnte. Die Grundidee ist, dass all diese Dinge völlig unabhängig sind (in der Geschäftslogik des Spektrums), also warum in der Welt würden sie alle Teil desselben Objekts sein. Wenn ich mich dafür entscheiden würde, dass Umarmungen länger dauern, könnte ich am Ende meine Steuern versauen. Geben Sie das IRS ein.
Wenn Sie jedoch an einem Physiksimulator arbeiten, sagen wir, und die Classical()
-Klasse würde Methoden / Objekte haben wie:
(mit freundlicher Genehmigung von Wikipedia)
Dieses Objekt wäre kein Gottobjekt. Es ist ein komplexes Objekt. Alles, was mit der Newtonschen Physik zu tun hat, durchläuft es, aber es ist kein Gott-Objekt. Es ist nur ein wirklich großes Objekt. Das oben genannte könnte Tausende von Zeilen Code sein.
Das Objekt Quantum()
wäre noch komplizierter, unnötig zu sagen.
Um es noch einmal zu wiederholen: Die Idee ist das Verhalten eines Programms, nicht Datenfluss :
es ist dir egal, ob ein einzelnes Objekt hält viele der Daten der App, oder ob die meisten Flüsse durchkommen müssen ein einzelnes Objekt. Was hat mehr Einfluss auf Wartbarkeit ist, wenn ein einziger Gott Klasse (tm) hält zu viel Verhalten (Geschäftscode).
Wenn Sie denken, dass es ein Problem gibt, könnten Sie versuchen, verschiedene Formen der Vermittlung oder hässlichere Muster wie
Wenn Sie sich mit der Größe und Komplexität einer Klasse nicht wohl fühlen, dann ist dies normalerweise ein guter Hinweis darauf, dass ein besseres Design möglich ist. Aber messen Sie nicht nur die Größe. Wenn eine Klasse leicht zu verstehen und zu befolgen ist, aber eine Menge Code enthält, bedeutet das nicht unbedingt, dass sie ein Kandidat für ein Re-Factoring ist. Ich habe gesehen, wie sich die Leute davon mitreißen lassen und das Durcheinander, das sie bei dem Versuch, die Dinge klein zu machen, verursacht, war viel schlimmer als der ursprüngliche Code. Andererseits habe ich mehrere Male von einem Ende zum anderen durchgelesen und hatte immer noch keine Ahnung, was sie tun.
Die Frage, die ich stellen möchte, lautet: Wenn ich das einem anderen Entwickler geben würde, wären sie in der Lage, es leicht zu verstehen und zu pflegen?
Wenn die Antwort ja lautet, besteht die Wahrscheinlichkeit, dass Sie nichts tun müssen. Wenn nicht, dann ist ein Re-Factoring in Ordnung.
Mit Bezug auf Gott-Objekte, lesen Sie Ihren Beitrag, klingt es wie diese Klasse zu viel tut. Ich frage mich, ob Sie den Zustand zunächst als Ausgangspunkt in eine Reihe von Modellobjekten ausrechnen können. Dann sieht Ihre Klasse mehr wie eine Konfigurationsfabrik aus.
Ich würde vorschlagen, dass die Physik- / Bewegungs-Engine definitiv vom Sprachinterpreter getrennt sein sollte; Obwohl der Sprachinterpreter Zugriff auf einige der öffentlichen Methoden und Eigenschaften der Physik-Engine benötigt, gibt es keinen Grund, warum die beiden Aspekte des Roboters in derselben Klasse liegen sollten. Der Sprachinterpreter selbst könnte ebenso wie die Bewegungsmaschine in einige Klassen unterteilt werden. Es kann ein Master-Control-Objekt geben, aber es sollte relativ wenig Code enthalten. Es, die Hauptbewegungsmaschine und die Hauptsprachenmaschine, sollten den größten Teil ihrer Arbeit auf die Gegenstände delegieren, die sie umfassen.
Ich denke, das Schlüsselprinzip hier ist "Zusammenhalt".
%Vor%.. ist nicht zusammenhängend.
Etwas wie:
%Vor%.. ist zusammenhängend, da alle Methoden ziemlich ähnlich sind. Du könntest 1000 zusammenhängende Methoden in einer Klasse haben und es wäre immer noch kein Gott-Objekt, da die Verantwortung der Klasse immer noch begrenzt ist.
Tags und Links java controller god-object