Thomas hat das wesentliche schon gesagt, von meiner Seite vielleicht noch eine Ueberlegung in eine etwas andere Richtung.
Vorweg, Simon, ein solches Modell würde sich eventuell anbieten, wenn LS Mehrfachvererbung kennen würde, das ist aber nicht der Fall. Und ist deswegen nicht wirklich wichtig, weil wie Thomas schon gesagt hat, in den UI-Klassen darf keine Logik stecken. Die UI-Klassen sind Interface zwischen Darstellung und Logik und damit in der Regel tendenziell mit "wenig Inhalt". Ich weiss jetzt nicht auswendig, ob das in der Service-App konsequent durchgeführt ist, da haben aber neben mir auch andere Leute noch die Finger drin gehabt.
In einer einer aktuellen Applikation von mir sieht das Modell kurz gefasst etwa so aus:
BaseDocumentClass -- SomeDocumentClass -- SomeDocumentUIClass
im Falle, dass da etwas erweitert werden sollte, könnte es dann so aussehen:
BaseDocumentClass -- SomeDocumentClass -- SomeExtendedDocClass -- SomeExtendedDocUIClass
Alternativ kann man natürlich auch Verbindungen über Attribute machen, so wie es Thomas und auch Notes macht, die zweiwege-Verbindung zwischen Frontend und Backend ist da nicht in jedem Fall notwendig (bei mir aktuell brauch ich sie nicht, was nicht heisst, dass es nicht nützlich sein könnte).
Anders ausgedrückt, das abstrakte BaseUIDoc ist in einem solchen Fall nicht nötig, sämtliche Basislogik, inklusive Event-Handling wie QuerySave steckt in der BaseDocumentClass
Uebrigens, genau diese Ueberlegungen sind ein wesentlicher Bestandteil davon, ob ein OO-Ansatz erfolgreich durchgeführt wird oder nicht.
