Das kommt ja auch sehr drauf an was du damit machen willst.
Manchmal sind in den sub-units nur einfache Funktionen dahinter.
Man könnte in die sub-units auch die Basisfunktionen einer Basisklasse implementieren, und
von dieser dann im main
Unit wieder ableiten, und schon hat man die Platform-Funktionen ausgelagert.
Ich finde auch den FMX.TPlatform-Ansatz generell ganz gut, wie verschiedene Services ausgeklammert werdern,
bin mir aber nicht sicher ob das immer richtig ist.
Z.B. ob ein ständiges Holen der Interfaxce nicht etwas ineffizient ist, wie z.B. Canvas-Routinen,
die ständig aufgerufen werden.
Generell mit RegisterXyz(); und im main
unit Interfaces erzeugen, das ist auch OK, aber ich denke
es wird meistens auch im main
unit ein allgemeiner Code gebraucht.
Der sollte eben nicht in Sub-Units redundant ausgeklammert werden.
Entkoppeln könnte man aber auch über TMessages, so das die entsprechenden Sub-Module nur über Messaging kommunizieren.
Jedenfalls finde ich das die Entkopplung von der Platform, wie auch immer, viel an Lesbarkeit bringt.
Und vor alem mal eine Wiedervervendung möglich macht.
Wenn man alles in einer
Unit mit 100 IDEFs verwurschtelt hat, mal ehrlich, das fasst doch keiner gerne nochmal an.
Von der Verbesserten Testbarkeit kleinerer Module mal ganz zu schweigen.
Aber einen klaren Favoriten habe ich da auch nicht (gibt es wohl auch gar nicht), mich ärgrt nur
das ich meistaus Zeitgründen auch wieder zu den IFDEFs komme,
um das dann später wenn Zeit ist wieder zu entflechten ab einer gewissen Größe.
Also es hängt Alles immer auch vom "Wollen" ab, und da bin ich leider auch immer viel zu willensschwach
@Himitzu
Na klar, so etwa
FMX.MyLibrary.MachWas.Mycode.Win32
Schön aufgeräumte codegruppen finde ich immer gut, aber oft entwickelt sich das erst über die Zeit.
Ich finde der Platform sollte hinten dran sein, ist aber Geschmachssache.
Rollo