Utilities-Datei in PHP?

Question

Was ist der beste Weg, um mit "Dienstprogramm" -Funktionen in einem OOP PHP-Framework umzugehen? Im Moment haben wir nur eine Datei mit mehreren Funktionen, die im gesamten System benötigt werden. (Zum Beispiel eine distribute()-Funktion, die einen Wert und ein Array akzeptiert und ein Array mit dem Wert in den gleichen Proportionen und den gleichen Schlüsseln wie das Eingabe-Array liefert.)

Ich habe mich immer "schmutzig" gefühlt, weil es ist überhaupt nicht objektorientiert. Ist es besser, diese als statische Methoden in verschiedene Klassen zu verschieben, oder ist das nur ein semantischer Workaround? Oder wird es nur eine Ebene in einem Rahmen geben, in dem einige Dinge aus der OOP-Struktur herausfallen werden?

Answer 1

Ich war schon immer pragmatischer bei Fragen wie diesen.

Wenn Sie Voll-OOP gehen wollen, sollten Sie diese natürlich in Klassen stecken. Diese Klassen werden jedoch nur Containerklassen sein, da sie keine Objekte darstellen.

Außerdem: Wenn Sie Klassen verwenden, müssen Sie entweder eine Instanz dieser Klasse verwenden, das Singleton-Muster verwenden oder jede Funktion als statisch deklarieren. Der erste ist langsamer (okay, vielleicht nicht so viel, aber in einem großen Rahmen werden solche Dinge auch groß - vor allem in interpretierten Sprachen wie PHP), während die zweite und dritte einfach nutzlos und einfach ein OOP-Wrapper sind für eine Reihe von Funktionen (insbesondere der dritte Ansatz).

EDIT: Fühlen Sie sich frei, mich falsch zu beweisen. Ich könnte. Ich bin nicht so erfahren und habe es immer so gesehen, aber ich könnte falsch liegen.

Answer 2

Ich denke immer an Utility-Funktionen als Erweiterungen der Standard-PHP-Funktionen. Sie sind nicht objektorientiert, weil Sie keinen wirklichen Nutzen davon haben, sie zu OO zu machen.

Answer 3

Ich neige dazu, eine Util() Klasse zu erstellen, die nur statische Methoden enthält, keine Attribute hat und nicht vererbt wird. Im Wesentlichen fungiert es als ein "Namespace" für eine Reihe von Utility-Funktionen. Ich werde zulassen, dass diese Klasse an Größe zunimmt, wird aber gelegentlich Methoden in eigene Klassen aufteilen, wenn klar ist, dass diese Methoden nur für die Arbeit mit bestimmten Arten von Daten entwickelt wurden oder wenn es klar ist, dass eine Gruppe verwandter Methoden verwendet werden sollte gruppiert in eine Klasse zusammen mit vielleicht einigen Attributen.

Ich denke, es ist vollkommen in Ordnung, von reinen OOP-Praktiken abzuweichen, solange der abweichende Code gut organisiert ist und keine architektonischen Mängel in Ihrem System verursacht, die das Verständnis und die Wartung erschweren.