Suche Kategirien Bezeichner der Konvention konform ist
MB
- php
- projektverwaltung
0 Nachtrag: Decorator
MB-1 pl1 1unitedpower
moin,
Ich hab ein Klassengebilde mit einfachen Vererbungshierarchien. Ich beziehe mich auf einene Superklasse AbstractClass
. Ich habe viele Service Klassen im Superklassen Konstruktor für die weiteren funktionen instanziiert.
abstract class AbstractClass {
protected function __construct () {
$this->fooService = new FooService;
$this->barService = new BarService;
}
}
Die Service Klassen gehören thematisch nicht wirklich zur der Superklasse AbstractClass
, sind aber wichtig genug für die jeweiligen Funktionen in der Superklasse AbstractClass
.
Also habe ich die Service Klassen Instanzen, die ich im Superklassen Konstruktor instanziiert habe, in eine zusätzliche Klasse zusammengefasst, die dann die Funktionen übernommen hat, die thematisch nicht zu der Superklasse AbstractClass
gehören. - Finde ich thematisch besser.
abstract class AbstractClass {
protected function __construct () {
$this->service = new ServiceClass;
}
}
class ServiceClass {
public function __construct () {
$this->fooService = new FooService;
$this->barService = new BarService;
}
}
Jetzt suche ich einen Kategorie Bezeichner, worunter die Service Klassen fallen können und Konvention konform ist. "Decorator" kann ich als Kategorien Bezeichner nicht nehmen, da sich ja diese Bezeichnung mit Design Patterns in Verbindung bringen lässt 😕.
lgmb
moin
Ich hab noch vergessen zu erwähnen, das ich strukturell eine ähnlichkeit mit den Decorator Design Patterns sehe. Daher wollte ich die Kategorienbezeichner verwenden, unter den die ServiceClass
fällt.
zur Veranschaulichung am Konkreten Beispiel: einer Ordner-Baumstruktur mit den Kategoriebezeichnern Abstracts
und Decorators
:
+ Project
+ Abstracts
> AbstractClass.php
> […]
+ Decorators
> ServiceClass.php
> […]
+ […]
lgmb
Hallo MB,
das ist kein Dekorator, sondern eine Art von Fabrik, die Services als Singletons liefert.
Das kann man machen, sofern die Services tatsächlich Singleton-tauglich sind, d.h. stateless.
Andernfalls wäre eine Servicefabrik die jedes Mal eine neue Instanz bereitstellt besser.
Rolf
moin,
das ist kein Dekorator, sondern eine Art von Fabrik, die Services als Singletons liefert.
Sry, das verstehe ich leider nicht.
Das kann man machen, sofern die Services tatsächlich Singleton-tauglich sind, d.h. stateless.
Du meinst new Singelton::getInstance()
. Was hat das mit den privaten Service Klassen zutun, die in einer Kontainer Klasse ServiceClass
bereit gestellt werden, die wiederum im AbstractClass
Konstruktor instanziiert wurde? Meine Service Klassen werden nur einmal Instanziiert um dann der AbstractenClasse
über $this->service->doSommething()
verdeckt zur Verfügung zu stehen, da die Service Klassen ja private sind und sich in öffentlichen Methoden der ServiceClass
teileweise ergänzen. Beispiel:
class ServiceClass {
private $fooService;
private $barService;
public function __construct () {
$this->fooService = new FooService;
$this->barService = new BarService;
}
public function doSomthing() : void {
$this->fooService->doAnything ();
$this->barService->doNothing ();
}
public
}
lgmb
Hallo MB,
verstehst Du nicht? Dein ServiceContainer passt für mich auf das Fabrik-Pattern. Eine Fabrik liefert auf Abfrage bestimmte Objekte.
Dass deine ServiceClass auch Methoden hat, die an Methoden der Services delegieren, hat Du vorher nicht geschrieben. Das würde ich aber auch nicht machen. Dann ist sie kein Service-Container mehr, sondern nutzt wiederum Services für eigene Arbeit. Und dann ziehst Du die Services wieder in einen eigenen Container hinaus? Das wäre nun over-engineering in höchstem Maß.
Ich habe dich so verstanden, dass ServiceClass nur eine Aufgabe hat: Instanzen von bestimmten Services bereitzustellen. Das ist eine Servicefabrik. Du hast ein paar spezielle Implementierungsdetails:
Es wäre klarer, wenn die ServiceClass die Services über Methoden bereitstellte. Das würde den Cache der Service-Instanzen gegen unbefugte Veränderung schützen. Und es ermöglicht eine lacy - hihi - lazy creation der Services. Bei Services, die sich ggf. nicht als Einzelexemplar eignen, weil sie einen veränderlichen Zustand haben, kannst Du dann fallweise auf das Cachen verzichten. Sowas muss der Nutzer des Services gar nicht wissen.
Wenn Du im Programmablauf Arbeit aus deiner Klassenhierarchie hinaus delegieren willst, erzeuge Worker-Services (die kann wiederum die Servicefabrik bei Bedarf liefern und aus den den erforderlichen Dienst-Services komponieren). Einen Worker für die Aufgabe XY kann eine Klasse dann bei der Servicefabrik einkaufen und ihn mit den benötigten Daten laufen lassen. Sowas bringt Entkoppelung, Wiederverwendbarkeit und Unittestbarkeit, kostet aber natürlich etwas Laufzeit.
Rolf
moin,
Dass deine ServiceClass auch Methoden hat, die an Methoden der Services delegieren, hat Du vorher nicht geschrieben.
Sry
Wenn Du im Programmablauf Arbeit aus deiner Klassenhierarchie hinaus delegieren willst, erzeuge Worker-Services. […]
Danke
lgmb
Ich habe Dir das schon eimal hier beschrieben
Also mache Dir den Unterschied zwischen Dependency Injection und Lacy Delegation klar.
MFG
Hallo pl,
Lacy Delegation
ich stelle mir gerade eine Delegation in spitzenbesetzter Unterwäsche vor 😂
Mein Tag ist gerettet...
Rolf
Hallo Rolf,
Lacy Delegation
ich stelle mir gerade eine Delegation in spitzenbesetzter Unterwäsche vor 😂
Mein Tag ist gerettet...
gut beobachtet, gefällt mir auch!! :-)
Ciao,
Martin
moin,
Ich habe Dir das schon eimal hier beschrieben
Und entschuldigung ich habe dir hier geantwortet
lgmb
Hallo MB,
ich werd das Gefühl nicht los, dass du versuchst das Pferd von hinten aufzuzäumen. Das betrifft nicht nur diesen Thread, sondern auch die beiden Nachbarthreads und einige Threads aus der Vergangenheit.
Du machst dir sehr viele Gedanken über die Organisation von Code, das ist auch wichtig. Nur treibst du das soweit, dass du völlig aus den Blick verloren hast, was du eigentlich organisieren möchtest.
Das ist ein bisschen so, als installierst du eine Stadtverwaltung für eine Stadt, die es nicht gibt. Und jetzt fragst du uns als Bürgermeister, wie du deine Behörden effizienter gesalten kannst. Was soll man denn darauf sagen?
Deine Probleme haben doch bestimmt einen konkreten Ursprung in der Realität. Erkläre uns dieses Problem so konkret wie du nur kannst, und abstrahiere es nicht soweit, bis die Substanz nicht mehr erkennbar ist. Dann kann man dir auch zielgerichtete antworten.
Viele Grüße
1UP
moin,
Deine Probleme haben doch bestimmt einen konkreten Ursprung in der Realität. […]
Natürlich gebe ich dir recht mit allem was du vermutest. Ich werde natürlich mein Projekt hier im Forum Vorstellen wenns fertig ist. Ich mein ihr habt ja auch mir unter die Arme gegriffen. Nur nicht jetzt. Hat Gründe 😕.
lgmb
Nun, ich habe nicht den Eindruck daß Du hier was lernst. Du kommst ja immer wieder mit denselben Fragen.
MFG
moin,
Nun, ich habe nicht den Eindruck daß Du hier was lernst. Du kommst ja immer wieder mit denselben Fragen.
Welche Frage? Werde bitte konkret. Es freund mich wirklich das du mir offenkundig deine Annahmen unterbreitest 😀. Ich hab gestern drei Threads aufgemacht mit underschiedlichen Fragen. Und ein Thread stellt ja nun mal eine Frage oder Fragen zu einem Thema. Ich habe vieles bestätigt bekommen und neue Einblicke erlangt in diesem Forum. Und für nix anderes ist das Forum doch da. Bitte fomulier die Frage anders und Konkreter damit ich drauf antworten kann 😉.
lgmb