nicht angemeldet
Tach!
ok. was könnte ich deine und @pl Meinung nach tun um Mein ziel zu erreichen?
Ich weiß nicht, was dein eigentliches Ziel ist. Die benötigte Funktionalität muss den Weg weisen.
Sie in Traits auszulagern, um alles dann wieder zu einer großen Klasse zusammenzufügen, macht die Sachlage nicht besser. Traits sind nicht die dafür vorgesehene Lösung.
Wenn ich alles zusammen in eine Ding verfrachte treten die genannten Probleme auf die ich erwähnte und es sieht sehr monolytisch aus. Was sind den Probleme bei der Traits eine von viele Lösungen sind?
Ein Beispiel hat RolfB schon genannt, Logging. Es ist das Hinzumixen von Funktionalität, nicht das Zusammenbauen der eigentlichen Klasse. Sagen wir, eine Klasse hat eine bestimmte Aufgabe. Was das konkret ist, spielt keine Rolle. Man möchte aber, dass die Klasse Debuginformationen liefern kann. Und nicht nur diese Klasse, sondern das soll generell möglich sein. Dazu kann man sich zunächst ein Interface definieren, das die benötigte Funktion beschreibt:
interface Debugable {
public function toDebug(): string;
}
Eine Klasse, die eine Debugausgabe ihrer selbst erstellen können soll, muss das Interface implementieren. Nun kann es sein, dass einige Klassen eine spezielle Ausgabe erzeugen sollen, bei anderen hingegen ist es immer derselbe Vorgang. Dessen Code möchte man nun nicht in jede Klasse kopieren, sondern nur einmal schreiben. Vererbung über eine Basisklasse wäre eine Möglichkeit, aber keine besonders gute. Die Basisklasse wird so zu einer Gott-Klasse und viele Klassen hängen aufgrund dieser Nebenfunktionalität mit dieser Basisklasse zusammen, auch wenn sie sonst keine gemeinsamen Merkmale haben. Mehrfachvererbung geht in PHP auch nicht. Wenn man weitere Basisfunktionalität haben möchte, muss man das so organisieren, dass es eine Kette ergibt: A->B->C. Wenn C zwar A und B braucht, aber A weder B braucht noch umgekehrt, muss B hier trotzdem die Dinge von A erben. Hier kann ein Trait helfen, der A enthält, in obigem Beispiel also die generische Implementation der Debugausgabe. Es ergibt sich keine verkettete Abhängigkeit, sondern der Trait kommt sozusagen von der Seite rein, während der Weg für eine Vererbung anhand der Notwendigkeiten der Hauptfunktionalität frei bleibt.
Unabhängig von obigem Beispiel bleibt die Frage, ob Vererbung oder auch Traits überhaupt für einen bestimmten Anwendungsfall sinnvoll sind, oder ob sich nicht vielleicht Wege finden, die Verbindungen nicht so starr zu gestalten. Eine Firma muss auch nicht für sämtliche Gewerke Mitarbeiter einstellen, sondern kann externe Dienstleister mit artfremden Aufgaben betrauen, aber auch als Zulieferer oder zum Ausführen bestimmter Zwischenschritte des Produktionsprozesses. Ähnlich kann man auch Code gestalten, und Aufgaben an Services delegieren. Services erledigen eine abgrenzbare Aufgabe. Der Vorteil daran ist, dass man diese Teilaufgabe auch separat entwickeln und testen kann, ohne viele Abhängigkeiten mit einer Monsterklasse pflegen zu müssen.
dedlfix.
Rolf B