ojsde/ojs — comment on commit 7d6ed5cbdadef1ee98cffa46e7d9d19f0453faeb
File: classes/plugins/PidPlugin.inc.php line 328
By jerico-dev:

Im Grunde hast du jetzt hier die Technik für ein generisches Plug-In in die neue Plug-In-Kategorie rübergezogen, also überall mit Hooks zu arbeiten, anstatt die plug-ins von aufrufendem Code aus zu benutzen. Ich gebe zu, dass ich kein großer Freund von dieser Art des Aufrufs bin, da sie die Code-Kapselung durchbricht. D.h.: Das PlugIn muss eine Menge über Code aus den verschiedensten Ecken "wissen", die überhaupt nichts miteinander zu tun haben. Das passt nicht gut zu der klassischen Idee für's Klassendesign: wenige Abhängigkeiten nach draußen und hohe innere Kohärenz. Dadurch bekommt dein Code auch gleich mehrere "Code Smells", siehe die super Liste in Fowler's "Refactoring"-Buch (z.B. jede Menge if's/switches, Herausholen undokumentierter Variablen aus dem Template, etc., etc.). Ich bin der Meinung, es ist besser, dass dort, wo PubIDs verwendet werden, auch der Code steht, um sie einzubinden. Denn da ist dann auch das notwendige "Wissen", wie die Einbindung am besten aussehen soll. Die Aufgabenverteilung ist dann klarer: Das Plug-In hat nur die Aufgabe PubIDs zu generieren, und der aufrufende Code bindet diese je nach Anwendungsfall spezifisch ein. Dass du es jetzt so löst und nicht anders, liegt mMn einfach nur daran, weil du zuerst ein generisches Plug-In hattest. Man nennt sowas "paving cow paths".