Uses: Interface vs. Implementation Section

[neo4a]

Zitat:

Zitat von brechi (Beitrag 1142497)

Zitat:

Zitat von neo4a (Beitrag 1142485)

- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code),

ich bin jetzt der "andere", für mich ist es nicht leichter zu warten,

Wir reden offensichtlich aneinander vorbei. Beschäftige Dich einfach auch einmal mit Clean Code. Es lohnt sich bestimmt auch für Dich und es ist auch auf Deutsch:

Interface Segregation Principle
Information Hiding Principle

BTW, es macht mir keinen Spaß mehr, mich mit Deiner Argumentation auseinanderzusetzen, weil ich Deinen "Ich bin nicht Deiner Meinung, denn ich mache es ja anders"-Stil substantiell etwas fade finde.

[DeddyH]

Diese Diskussion ist nicht nur flüssig, sie ist schon überflüssig. Beide Varianten haben ihre Vor- und Nachteile, also finde ich, das soll jeder so machen, wie er für richtig hält. Sich hier gegenseitig anzupflaumen oder mit irgendwelchen Prinzipien um sich zu werfen ist doch eher kontraproduktiv.

[Bummi]

@DeddyH :thumb:

[Furtbichler]

Zitat:

Zitat von neo4a (Beitrag 1142485)

Ich bin weder kein Praktiker noch bin ich kein Ästhet, deshalb noch meine 3. Meinung:

Alle Units da hin, wo sie hingehören, weil
- es sich so gehört (Convention), ...

Zitat:

Zitat von Furtbichler (Beitrag 1142482)

Die Ästheten sagen "Alle Units da hin, wo sie hingehören, ..."

Sei mir nicht böse, aber ich finde, Du bist ein Ästhet. Aber einer, der weiss, warum er einer ist. Noch besser.

Zitat:

... und es kompiliert trotzdem: Ist das nicht herrlich?!

Ick könnt heulen vor Glück ;-)

Zitat:

Zitat von brechi (Beitrag 1142497)

ich bin jetzt der "andere", für mich ist es nicht leichter zu warten...

Für dich besteht 'warten' offenbar nur aus der Tätigkeit, fremden Code erstmalig zum kompilieren zu bringen. Klar, dafür ist es natürlich einfacher, wenn alle Units im Interface-Teil sind. Es ist übrigens noch einfacher, wenn alle Units im Projektquellcode angegeben sind. Denn dann muss ich nicht mal in die einzelnen Units rein. Also fordern wir: Alle Units im Projektquelltext angeben?

Code zu warten bedeutet aber in erster Linie: Verstehen. Und zum Verständnis der Funktion ist es nun mal besser, unwichtige Details zu verstecken. Das gilt nicht nur für Programmcode, sondern ist generell wichtig.

Wenn ich jemanden den Auftrag gebe, Brötchen zu holen, ist es mir vollkommen egal, ob er dazu seinen braunen Mantel oder die Schijacke anzieht. Und ob er bar oder mit Karte bezahlt. D.h. der Auftrag (Inteface) enthält die Information 'Ich will Brötchen vom (uses) Bäcker'. Ich bevorzuge nämlich Brötchen vom Bäcker. Vom Supermarkt schmecken sie mir nicht.

Also:

Delphi-Quellcode:

Unit Frühstück;
Interface 
uses BrotSorten, Bäcker;
Procedure BesorgeBrötchen (MeinLieblingsBäcker : TBäcker; Anzahl : Integer; out MeineBrötchen : TBrötchenTüte);

// Und wie Du das machst ist mir sowas von egal
Implementation
uses SkiJacke, BraunerMantel;

So. Wenn es mir denn nur um die Brötchen ginge, dann so:

Delphi-Quellcode:

Unit Frühstück;
Interface 
uses BrotSorten;
Procedure BesorgeBrötchen (Anzahl : Integer; out MeineBrötchen : TBrötchenTüte);

// Und wie Du das machst und woher Du die Dinger holst ist mir sowas von egal
Implementation
uses Bäcker, Supermarkt,SkiJacke, BraunerMantel;

Nun kommt brechi und sagt: "Alles ins Interface, dann ist das leicher zu verstehen"

Delphi-Quellcode:

Unit Frühstück;
Interface 
uses BrotSorten, // BrechiSeinLibOrdner/Brote/Src
    Bäcker, Supermarkt, // ..fasel
    SkiJacke, BraunerMantel; // blub

Procedure BesorgeBrötchen (Anzahl : Integer; out MeineBrötchen : TBrötchenTüte);

Implementation

brechi, Du kannst uns auch erklären, was der braune Mantel und die Skijacke mit dem Brötchenholen zu tun haben (sollen). ;-)

Zitat:

Zitat von brechi (Beitrag 1142497)

Delphi-Quellcode:

  uses
    windows, classes, sysutils, // delphi
    fastreport, fastscript, fastirgendwas // fastreport: libs/fastreport/src
    teechart, teetools; // teechart: libs/teechart/src

Ahso. Wenn ich das so mache, und dann aber noch etwas auf meine Form schmeisse (eine von 670 übrigens, wer soll das so hübsch formatieren?), dann passiert was..? Die Unit wird hintenran gepackt und ich darf sie wieder einsortieren. Du scheinst nicht unter Arbeitsüberlastung zu leiden. Ich habe jedenfalls keine Zeit für so einen Schnickschnack.

Übrigens... Was passiert, wenn der "Andere" seine Bibliotheken nicht unter "libs/irgendwas/src' hat? Dann ist dieser Kommentar eine ... Genau. Eine Lüge. Unnütz und häßlich. Aber es kompiliert ja.

Zitat:

Zitat von DeddyH (Beitrag 1142507)

Diese Diskussion ist nicht nur flüssig, sie ist schon überflüssig.

Nö. Der Stil ist daneben, die Diskussion nicht.

Zitat:

Sich hier gegenseitig anzupflaumen ... ist doch eher kontraproduktiv.

Jau.

Zitat:

...oder mit irgendwelchen Prinzipien um sich zu werfen

Da es sich bei den 'Prinzipien' nicht um 'irgendwelche' handelt, sondern um die, an die sich jeder Programmierer halten sollte, finde ich es auch wichtig, diese zu nennen.

Wie gesagt: Wer meint, das er nur einen Uses-Teil braucht (wie alle C# Programmierer), soll es gerne so machen. Aber bitte nicht mit Wartbarkeit kommen, und 'Kompilieren' meinen. Und nicht mit 'Übersichtlich' kommen, wenn man komplexen Code nicht mal im Ansatz versteht.

Da nun aber letztendlich jeder seinen eigenen Geschmack hat und selbst ein Messi in seiner Welt Ordnung im Chaos hat, kann man sich natürlich immer hinter dem Argument: "Also für mich ist das eben übersichtlicher" verstecken.

Aber eins ist klar: Freundlich bleiben und respektvoll reden. Und das fehlt hier zum Schluss doch etwas.

[neo4a]

Zitat:

Zitat von DeddyH (Beitrag 1142507)

Diese Diskussion ist nicht nur flüssig, sie ist schon überflüssig. Beide Varianten haben ihre Vor- und Nachteile, also finde ich, das soll jeder so machen, wie er für richtig hält.

Diese Diskussion hat eine Eigendynamik bekommen und die Frage, was wohin gehört, ist dabei m.E. nur der Platzhalter zu einer grunsätzlicheren Überlegung.

Ein Bild: Solange ich mit meinem Motorrad nur in meinem Hühnerstall fahre, interessiert es kaum jemand, ob ich Links- oder Rechtsverkehr praktiziere. Sobald ich mich auf die öffentliche Straße ...

Auf unsere Diskussion übertragen bedeutet das: Jeder darf gern seine eigene Meinung haben, solange er in seinem Delphi-Hühnerstall nur sich selbst verantwortlich ist. Darüber hinaus gelten halt längst anerkannte Regeln und die Meinung eines Einzelnen ist da nicht mehr so sehr maßgeblich. Ich gebe zu, es ist nur für die relevant, die bestrebt sind, es "richtig" zu machen.

Aus diesem Blickwinkel ist die Diskussion inhaltlich tatsächlich längst entschieden.

[DeddyH]

Nur ist es bei diesen Regeln oftmals so, dass man sich nur schwer konsequent an eine halten kann, ohne damit eine andere zu verletzen.

[neo4a]

Zitat:

Zitat von DeddyH (Beitrag 1142515)

Nur ist es bei diesen Regeln oftmals so, dass man sich nur schwer konsequent an eine halten kann, ohne damit eine andere zu verletzen.

In der Tat überlappen sich an manchen Stellen die Bedeutungen und führen je nach Gewichtung zu anderen Ausführungen. Das ist schon okay. Aber man muss sie ja deswegen nicht komplett ignorieren, oder?!

[DeddyH]

Das hat ja auch niemand behauptet. Die richtige Balance zu finden ist die Kunst. Und hier muss eben jeder für sich entscheiden, welche Regel ihm wichtiger ist.

[Daniel]

Zitat:

Zitat von DeddyH (Beitrag 1142507)

Diese Diskussion ist nicht nur flüssig, sie ist schon überflüssig. Beide Varianten haben ihre Vor- und Nachteile, also finde ich, das soll jeder so machen, wie er für richtig hält. Sich hier gegenseitig anzupflaumen oder mit irgendwelchen Prinzipien um sich zu werfen ist doch eher kontraproduktiv.

Zitat:

Zitat von Bummi (Beitrag 1142511)

@DeddyH :thumb:

Bei manchen Themen gibt es halt kein "richtiges" Ergebnis. Wichtig ist - denke ich - das Bewusstsein, dass es hier verschiedene Arten gibt, die beide mit individuellen Merkmalen behaftet sind.

[neo4a]

Zitat:

Zitat von DeddyH (Beitrag 1142517)

Das hat ja auch niemand behauptet. Die richtige Balance zu finden ist die Kunst. Und hier muss eben jeder für sich entscheiden, welche Regel ihm wichtiger ist.

Genau das meine ich mit substantiell: Ausgehend von Regeln und Konventionen. Wer hier aber seine Meinung den Regeln und Konventionen gleichstellt oder sogar überordnet, verabschiedet sich leider inhaltlich aus der Diskussionsrunde, weil dann vor allem die gemeinsame Basis fehlt.

[DeddyH]

Das vorrangige Ziel einer jeden Diskussion sollte der Austausch von Argumenten sein und nicht das Durchdrücken der eigenen Meinung. Gerade bei Themen wie diesem kann so eine Diskussion aber nur ergebnisoffen geführt werden (siehe Daniels Post), was wiederum voraussetzt, dass alle Teilnehmer Willens und in der Lage sind, die Argumente der anderen zu prüfen und deren Meinung zu akzeptieren. Und genau das vermisse ich in letzter Zeit leider immer häufiger in diesem Forum, so auch hier.

[himitsu]

Hier kann es auch kein 100% Richtig oder Falsch geben.

Zitat:

Die Ästheten sagen "Alle Units da hin, wo sie hingehören, ..."

Und wer sagt wo sie hingehören?

Die Uses-Klausel hat nunmal eigentlich absolut nichts mit Interface oder Implementation zu tun.
Gäbe es keine Kreuzreferenzen, würde also ein einziger Uses-Abschnitt vollkommen reichen ... z.B. zwischen "UNIT xyt;" und "INTERFACE" und schon gäbe es kein Problem mehr. :angle:
Vorschlag zur Versöhnung: Wir machen keine Kreuzreferenzen mehr und lassen das USES entsprechend von Emba verschieben.

Mit Implementation oder Interface kann mal also nur steuern "wann" etwas geladen wird und das ist IMHO "nur" für Kreuzreferenzen wichtig.

Denn im Interface angegeben, werden sie nicht "veröffentlicht".
> es ist in einer anderen Unit nicht erkennbar welche Units die eingebundenen Units wiederum einbinden, noch werden irgendwelche Typen, Funktionen, Variablen oder Konstanten einer eingebuntenen Unit nach außen veröffentlicht/durchgereicht, egal ob diese in der Implementation oder im Interface eingebunden wurde.

Die einzigen Wirkungen sind, worauf der Unterschied "Implementation" oder "Interface" Einfluß besitzt:

• in welcher Reihenfolge werden Unit eingebunden
  • im Interface eingebundene Units werden immer vor der Unit geladen, welche sie eingebunden hat
    deren Register-Prozedur und der Initialization-Abschnitt werden also immer ausgeführt, bevor die eigene Unit geladen wird
  • in der Implementation eingebundene Unit "können" auch erst später geladen/initialisiert werden, also auch erst nachdem irgendein Code der ladenden Unit ausgeführt würde
  • beim Entladen ist die Reihenfolge natürlich andersrum
• außer daß man in der Implementation natürlich nur auf Dinge von Units zugreifen kann, welche auch "vorher" deklariert wurden (mehrere USES, im selben Bereich, sind ja nicht möglich, so wie bei TYPE, VAR und CONST), hat dieses nach Außen keine Wirkung ... nix vonwegen "veröffentlichen" des Interface-Zeugs oder so
• "ich" habe gerne (viele) zusammengehörrige Units auch zusammenhängend eingebunden (kleine Grüppchen)
  würde ich da jetzt diese auch noch auf Implementration/Interface aufteilen, wären meine Gruppen "kaputt"

Was nun der/die Einzelne daraus für Schlüsse zieht und wie er/sie das letztendlich verwendet, ist jedem selber überlassen.




Clean Code hin oder her, jede(r) kann machen was er/sie will und wie er/sie es mag.
Für mich ist letztendlich das Fehlerpotential ausschlaggebend und für mich zählen unnötige und fahrlässig platzierte globale Variablen genuso dazu, wie Implementationsunits (Ladereihenfolge).

Zu Clean Code:
- ja, es hat hier und da gute Ansätze, aber es ist keine "Vorschrifft" und ist auch nicht immer der Weißheit letzer Schluß
- die einzigen wirklichen Vorschriften sind die Syntaxvorgaben


*hau*, isch habe gesprochen
*friedenspfeife rauch*
*hust* *röchel*

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1142534)

[list][*] in welcher Reihenfolge werden Unit eingebunden[list][*] im Interface eingebundene Units werden immer vor der Unit geladen, welche sie eingebunden hat
deren Register-Prozedur und der Initialization-Abschnitt werden also immer ausgeführt, bevor die eigene Unit geladen wird

Ich hatte Dir diesbezüglich schon mal irgendwann zaghaft widersprochen.
Bei meinem Test http://www.delphipraxis.net/158879-p...ihenfolge.html konnte ich das nämlich nicht nachvollziehen.
Eigentlich war ich auch davon ausgegangen, dass man sich auf die Initialisierungsreihenfolge verlassen kann. Offenbar ist dies aber nicht so.
Jedenfalls bin ich auf das Problem gestoßen, da eine Liste in einer verwendeten Unit entgegen meiner Erwartung nicht rechtzeitig instanziiert wurde.

Aktuell habe ich jetzt das Problem nicht und auch nicht weitere Tests unternommen, aber möglicherweise hängst Du Dich doch etwas zu weit aus dem Fenster...?

[himitsu]

Ist jetzt vielleicht ein bissl extrem, das Beispiel, aber so auf die Schnelle dahingetippt:

- alle Units, bis auf Eine in der Implementation eingebunden
- nur bei einer Unit (UnitG) kann ich dir genau sagen wann diese geladen/freigegeben wird.
> ganz am Anfang und ganz zum Schluß (da Diese immer im Interface eingebunden wurde)



Die Einbindung in der DPR entspricht der Einbindung im Interface einer Unit.

Du kannst aber auch gerne die Units aus der DPR rausnehmen und in eine weitere Unit verlegen (alles in die Implementation oder alles ins Interface).
Da es mir hier nur um die Reihenfolge der eingebundenen Units ging und wie diese initialisiert werden ... ist es grundsätzlich erstmal egal, ob diese in er DPR oder in einer weiteren Unit eingebunden wurden.


Gegeben ist also

Delphi-Quellcode:

uses UnitG, Unit1, Unit2, Unit3;

begin
  UnitG.DoLog('Main');
end.

// der Rest steht in der Demo

und nun versuch mir zu sagen in welcher Reihenfolge diese Units geladen werden.

Das kann dir keiner zu 100% beantworten, außervielleicht die, welche den Compiler/Linker erstellt haben, falls sie das überhaupt wissen.
(abgesehn derer, welche es ausprobieren, versuchen eine Regelmäßigkeit zu erkennen und dann hoffen ihr so erlangtes Teilwissen würde immer und in allen Situationen stimmen)

[implementation]

Zitat:

Zitat von himitsu (Beitrag 1142534)

Die Uses-Klausel hat nunmal eigentlich absolut nichts mit Interface oder Implementation zu tun.
Gäbe es keine Kreuzreferenzen, würde also ein einziger Uses-Abschnitt vollkommen reichen ... z.B. zwischen "UNIT xyt;" und "INTERFACE" und schon gäbe es kein Problem mehr. :angle:
Vorschlag zur Versöhnung: Wir machen keine Kreuzreferenzen mehr und lassen das USES entsprechend von Emba verschieben.

Full Ack! Genauso sehe ich das auch. :thumb:
Und das ist der Grund weshalb ich hier eine Argumenatation mit "Clean Code" für vollkommen unangebracht halte.
Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

[brechi]

Zitat:

Zitat von implementation (Beitrag 1142576)

Zitat:

Zitat von himitsu (Beitrag 1142534)

Die Uses-Klausel hat nunmal eigentlich absolut nichts mit Interface oder Implementation zu tun.
Gäbe es keine Kreuzreferenzen, würde also ein einziger Uses-Abschnitt vollkommen reichen ... z.B. zwischen "UNIT xyt;" und "INTERFACE" und schon gäbe es kein Problem mehr. :angle:
Vorschlag zur Versöhnung: Wir machen keine Kreuzreferenzen mehr und lassen das USES entsprechend von Emba verschieben.

Full Ack! Genauso sehe ich das auch. :thumb:
Und das ist der Grund weshalb ich hier eine Argumenatation mit "Clean Code" für vollkommen unangebracht halte.
Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

Ich stimme euch beiden da voll zu :)

[Furtbichler]

Zitat:

Zitat von implementation (Beitrag 1142576)

Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

Hä? Irgendwie nicht, aber irgendwie doch? Wer sieht was nicht, hängt aber ab? Häää? Diese Aussage ist -sagen wir es vorweihnachtlich- ein wenig weißbärtig.

Der Implementierungsteil ist versteckt seine Details, der Interface-Abschnitt nicht. Per Definitionem. Klar ist da nicht wirklich was versteckt, denn ich kann ja in den Quelltext reinschauen. Aber wie die Funktionen der Unit genau umgesetzt ist und mit welch fiesen geheimen Trickunits gearbeitet wird... Also das ist.. doch ... irgendwie... wie soll ich's ausdrücken... Verborgen. Also, von der DCU her. Irgendwie schrietegal, wie der Autor das umgesetzt hat. Aber er sagt uns (über das Interface), was für andere Units wir benötigen. Klar benötigt man auch irgendwie die Units im Implementierungsabschnitt. Zum kompilieren. Logisch.

Aber da die ganze Zeit vom Quelltext die Rede ist, kann man das wohl vernachlässigen. Oder meintest Du das?

Mal was anderes:
Übrigens verdiene ich mein Geld damit, meine Units im Implementationsabschnitt anzugeben. Ob ich genauso wenig/viel Geld verdienen würde, wenn ich sie alle im Interfaceabschnitt angebe? Keine Ahnung. Ich bin doch nicht so blöd und probier das aus. Nacher bin ich arbeitslos, oder meine Tastatur explodiert oder so.

Gleiches könnte übrigens den Programmierern passieren, die vielleicht mal ausprobieren wollen, wie es sich anfühlt, wenn man eine Unit in den Implementation-Abschnitt verfrachtet.

Also Leute: Auf gar keinen Fall die andere Seite ausprobieren, oder -was noch schlimmer wäre- der anderen Seite zugestehen, das sie Recht haben könnte. Schwerer Fehler! Eingeständnis der eigenen Unzulänglichkeit.

In diesem Sinne möchte ich das Niveau nochmals verschieben:
Implementationsusesverwendungsverweigerer sind Schlaumeier! Oder waren es die Implementierungsabschnittsusesverwender, die Klugscheißer sind? Oder umgekehrt? Passt beides.

Vielleicht kommen wir so weiter. :stupid:

[implementation]

Zitat:

Zitat von Furtbichler (Beitrag 1142622)

Zitat:

Zitat von implementation (Beitrag 1142576)

Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

Hä? Irgendwie nicht, aber irgendwie doch? Wer sieht was nicht, hängt aber ab? Häää? Diese Aussage ist -sagen wir es vorweihnachtlich- ein wenig weißbärtig.


Der Implementierungsteil ist versteckt seine Details, der Interface-Abschnitt nicht. Per Definitionem.

Es geht lediglich um die Uses-Klausel. Erkläre mir bitte mal, inwiefern der implementation-Teil die Uses-Klauseln mehr versteckt als der interface-Teil.
Egal, in welchem Teil du die Klauseln jetzt hinpackst: Alle anderen Units, die deine Unit einbinden, können die Klauseln so oder so nicht sehen. Und egal, in welchem Teil die Klausel liegt, Units die deine Unit einbinden, hängen immer von den in deiner Unit eingebundenen ab. Dependency-Tree.
Insofern gehört die Klausel eigentlich in keinen von beiden Teilen, denn das Verstecken betrifft sie überhaupt nicht.

Zitat:

Zitat von Furtbichler

Also Leute: Auf gar keinen Fall die andere Seite ausprobieren, oder -was noch schlimmer wäre- der anderen Seite zugestehen, das sie Recht haben könnte. Schwerer Fehler! Eingeständnis der eigenen Unzulänglichkeit.

Schau dich mal um. Siehst du die Glaswände? Da hinten steht sogar ein Schild: "Steinekatapultieren auf eigene Gefahr"

[Furtbichler]

Zitat:

Es geht lediglich um die Uses-Klausel. Erkläre mir bitte mal, inwiefern der implementation-Teil die Uses-Klauseln mehr versteckt als der interface-Teil.

Na weil die Units dort aufgelistet sind und nicht im Inteface-Abschnitt.
Folgendermaßen kann der Code gelesen werden: "Ich als Unit benutze diese Units im Implementierungsabschnitt für die Implementierung meiner nach außen hin sichtbaren Funktionalität, und um diese Funktionalität nutzen zu können, müsstest Du nur die Units in meinem Interface-Abschnitt bei dir einbinden."

Zitat:

Schau dich mal um. Siehst du die Glaswände? Da hinten steht sogar ein Schild: "Steinekatapultieren auf eigene Gefahr"

Nö. Hier nicht. Hier sind die Wände ganz weich :stupid: . Das mit den Glaswänden (cool!) muss bei Dir sein :-D.

Übrigens, falls es dir nicht aufgefallen ist: Ich blase ins gleiche bornierte Horn wie Du. Nur ich habe es schon bemerkt und verarsch dich mit dem letzten Absatz. Mach das mit dir selbst auch mal, zur Abwechslung. Dann wirst Du auch wieder lockerer.

[DeddyH]

Ist eigentlich schon jemandem aufgefallen, dass diese "Diskussion" zu nichts führt außer persönlichen Anfeindungen? Aber da ich sowieso die ganze Zeit geflissentlich ignoriert werde, dürfte dieser Einwand auch wieder im Sande verlaufen. Also zieht Euch meinetwegen die Boxhandschuhe an und schlagt Euch gegenseitig die Köpfe ein :twisted:

[Daniel]

Ich halte das Thema für hinreichend behandelt.