Trait oder Elternklasse in einer Klassen Gruppe?

[Rolf B]

Hallo pl,

Bei einem Interface (IF) steht die Reihenfolge fest in welcher die Methoden des IF aufgerufen werden

Das klingt jetzt merkwürdig, aber ich denke, ich weiß was Du meinst: Für eine bestimmte Aufgabe, die man mit Hilfe des Interfaces erledigen will, ist eine bestimmte Reihenfolge von Methodenaufrufen auf diesem Interface erforderlich. Wenn Du sagen wolltest, dass sämtliche Methoden eines Interface stets in einer fixen Reihenfolge zu rufen sind, dann würde das meinen eigenen Erfahrungen im Gebrauch und in der Bereitstellung von Interfaces widersprechen.

Injizieren kann man grundsätzlich auf zwei Arten: Bei Konstruktion oder nachher. Unity von Microsoft unterstützt z.B. Injektion im ctor, über Properties oder über Methoden. Es injiziert aber immer alles, wofür es eine Kanüle findet. Deshalb habe ich auch schon Injektionsmethoden gebaut und vor Unity versteckt (bzw. auf eine Bekanntgabe an Unity verzichtet), um sie bedarfsweise nutzen zu können.

Dass Traits und Interfaces Ideen sind, die nicht auf PHP beschränkt sind, ist klar - aber nicht jedes Programmierkonzept lässt sich in jeder Sprache elegant umsetzen. Wenn ich ein Konzept nur mit mühsamen Krücken nutzen kann, dann macht das den Code eher schlechter als besser. Traits wären z.B. in C# vor .net 3.0 ohne einen Code-Generator nicht sinnvoll machbar gewesen. Das spricht dann wieder für dein Handwerkskonzept: man muss wissen, was der eigene Werkzeugkasten hergibt, und um man im Zweifelsfall einen Meißel in der Kiste hat, mit dem man auch mal eine Schraube eindrehen kann.

So wird man auch am Ende eigener Entwicklungen sämtliche Muster der GoF in seinem eigenen Code vorfinden

Sicherlich. Wenn man das vom Pattern gelöste Problem hat, wird man das Pattern im Zweifelsfall selbst entwickeln. Das ist ja keine Raketenwissenschaft. Es ist Handwerk. Sprich: Standardlösungen für Standardprobleme, die der Handwerker ohne langes Nachdenken anwenden kann. Das ist die Idee des GoF Buchs - man lernt diese Standardlösungen kennen. Das spart schlichtweg Zeit, und hilft anderen, die GoF ebenfalls kennen, den eigenen Code zu verstehen. Machmal bringt einen GoF auch auf elegante Lösungen für Probleme, für die man vorher nur eine mühsame Bastellösung hatte. Wenn man andererseits zwanghaft auf GoF Patterns zurückgreift, weil man meint, für alles ein fertiges Pattern nutzen zu müssen, hilft es dem Code überhaupt nicht (ich denke da an einen Klempnerlehrling, der eine 2m Rohrleitung aus 50 Fittings zusammensteckt...).

Rolf