Tach!
ich hab pl so verstanden das man von innen nach ausen entwickeln sollte.
Du gehst von dem aus, was letztlich verwendet werden soll. Zumindest bei der Planung. Wenn da zwei oder mehr Klassen sind, die ähnliches tun, dann kann daraus eine Basisklasse entstehen. Zum Beispiel sind die Validatorregeln unterschiedlich in ihrem eigentlichen Verhalten, aber gleich in der Verwendung. Vielleicht haben sie eine gemeinsame Funktionalität, dann kann diese in eine Basisklasse ausgelagert werden. Vielleicht brauchen sie aber nur ein gemeinsames Interface, weil zum Beispiel isValid() die einzige Funktion ist, die sie haben müssen, die Ausführung aber immer unterschiedlich ist. Du planst jedenfalls erstmal diese Validatorregelklassen und lagerst dann die Gemeinsamkeiten in eine Basisklasse aus oder definierst das Interface, oder beides.
Soweit so sinnvoll. Das war es dann aber auch schon mit der Hierarchie an dieser Stelle. Es wird am Ende kein großes Gebilde entstehen, mit der Response an der Spitze, weswegen das Beginnen mit der Response keine für mich nachvollziehbare Schlussfolgerung daraus ist. Stattdessen werden eher viele kleine Hierarchien entstehen, wenn überhaupt die Notwendigkeit der Auslagerung in Basisklassen besteht. Wenn du das Prinzip der Trennung nach Zuständigkeiten berücksichtigst, arbeiten die Teile deines Frameworks relativ autonom und sind nicht auf Erbschaften angewiesen. Wenn sie mit anderen zusammenarbeiten, dann in Form der Übergabe als Parameter. Am Ende spielt die Hierarchieplanung eine untergeordnete Rolle, wenn es kaum Hierachien gibt.
dedlfix.