Also die Lösung ist sehr unsauber, denn man geht davon aus, das die Eigenschaften 'Datasource', 'ReadOnly' und 'Color' unterschiedlicher Klassen eine identische semantische Funktionalität aufweisen, obwohl sie offenbar nichts miteinander zu tun (=keinen gemeinsamen Vorfahren) haben.
Desweiteren funktioniert der Ansatz auch nur dann, wenn die Eigenschaften überall auch wirklich so heißen. Bei DevExpress z.B. klappt das schon nicht mehr. Dort heißen die Properties "TcxDBTextEdit.Style.Color", "TcxDBTExtEdit.Databinding.Datasource" und "TcxDBTextEdit.Properties.ReadOnly".
Das ist Anti-
OOP. Da kann man dann gleich aufhören mit dem Programmieren und Klempter werden. Obwohl, die arbeiten auch sauber und nach Plan.
Sauber wäre z.B. ein ModifyController für jede (Basis-)
DB-Klasse und eine Factory, die einem den ModifyController anhand der TDBxxxEdit-Klasse liefert. Damit kann man dann auch sehr elegant auf die Fälle eingehen, bei denen die Properties anders heißen.
Das ist einsfixdrei gemacht, erweiterbar, übersichtlich usw. Mit diesem
RTTI-Rumgefrickele mag das funktionieren, aber das tun mit Duct-Tape reparierte Autos auch. Irgendwie.
Verständnisfrage; Stahli's Methode funktioniert auch dann, wenn man Formulare in einer vorkompilierten
BPL verwendet?
Zitat
Baum-Darstellung
