Uses: Interface vs. Implementation Section

[neo4a]

Vielleicht kommt ein Teil der Meinungspolemik in diesem Thread auch von der unterschiedlichen Herangehensweise bzw. Nutzung von Delphi?

Beim RAD-Ansatz übernimmt ja Delphi quasi die Verwaltung der Units und packt sie alternativlos und korrekt in den Interface-Bereich.

Sobald ich jedoch eigene Klassen oder Forms/Frames ohne RAD einsetze, bin ich allein der "Bauherr" meiner Units und der Verwalter von deren Referenzen. Und Furtbichler könnte sich z.B. auch auf N.Hodge berufen, der hier Regeln aufstellt und da besonders darauf hinweist, dass man funktionierenden Code haben kann, ohne irgendwelchen Code in der Interface Section (mittels eines DI-Frameworks).

Hier kommen dann auch schon Entwicklungs-Prinzipien und -Methoden (Law of Demeter, Testable Code, Clean Code) in's Spiel, die etwas über den bloßen Wunsch hinaus gehen, immer alles im Blick haben zu wollen.

[DeddyH]

Zitat von neo4a:

Beim RAD-Ansatz übernimmt ja Delphi quasi die Verwaltung der Units und packt sie alternativlos und korrekt in den Interface-Bereich.

Nicht immer. Wenn man auf andere Formulare zugreifen möchte, die entsprechende Unit aber noch nicht eingebunden hat, packt Delphi diese in den implementation-Abschnitt, wenn man die Nachfrage bestätigt.

[neo4a]

Zitat von DeddyH:

Zitat von neo4a:

Beim RAD-Ansatz übernimmt ja Delphi quasi die Verwaltung der Units und packt sie alternativlos und korrekt in den Interface-Bereich.

Nicht immer. Wenn man auf andere Formulare zugreifen möchte, die entsprechende Unit aber noch nicht eingebunden hat, packt Delphi diese in den implementation-Abschnitt, wenn man die Nachfrage bestätigt.

Das stimmt, aber wer macht denn freiwillig so etwas?

Zitat von Delphi Pretty Good Practices #4 - Do Work in Classes:

One way to tell you are not doing this is if you tend to do “OnClick” programming, or relying on event handlers to do the work of your application.