AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Uses: Interface vs. Implementation Section

Ein Thema von Martin W · begonnen am 16. Dez 2011 · letzter Beitrag vom 22. Dez 2011
Thema geschlossen
Seite 2 von 7     12 34     Letzte »    
Benutzerbild von sx2008
sx2008

Registriert seit: 16. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#11

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 05:39
Anscheinend gibt es hier zwei entgegengesetzte Meinungen, ich bin gleicher Meinung wie "Furtbichler".
Wenn es richtig wäre alle Units im Interface-Abschnitt einzubinden warum besteht dann überhaupt die Möglichkeit die Uses-Klausel im Implementation-Abschnitt zu benützen?

Ich glaube ja nicht, dass die Entwickler von Delphi unnötige Sprachfeatures erfunden haben sondern dass "himitsu" hier falsch liegt.

Hauptargument:
* wenn man eine Unit im Implementation-Abschnitt einbindet hilft dies dem Compiler weil er bei Änderung der Unit weniger kompilieren muss und interne Symboltabellen kleiner werden
Bei grossen Projekten mit Hunderten von Units kann das einen grossen Unterschied ausmachen,
denn wenn jede Unit direkt oder indirekt die Symboltabelle jeder anderen Unit benötigt dann ist das ein quadratischer Zusammenhang.

Nebenargumente:
* Es gibt in der objekt-orientierten-Programmierung das Prinzip des Information hiding.
Verberge soviel wie möglich von der inneren Struktur.
Mache alles privat mit Ausnahme der Dinge die öffentlich sein müssen.
Das kann man so auch auf die Sichtbarkeitmachung der Abhängigkeiten der verschiedenen Units anwenden

* Es gibt z.B. das Freeware Tool Icarus.
Es zeigt nach einer Analyse des Sourcecodes nicht nur unbenützte Units an, sondern zeigt auch die Units, die man vom Interface- in den Implemenation-Abschnitt verschieben kann.
Die Programmierer von Icarus haben sich bestimmt sehr gründlich mit dem Unitkonzept von Delphi auseinandergesetzt und bieten hier bestimmt keine sinnlose Funktion an.
 
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#12

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 09:30
Vielleicht gab es ja anfangs nur die obere Uses-Klausel?

Die Andere wurde später eingebaut, als man merkte, daß es sonst, bei Kreuzreferenzen, unüberwindbare Hindernisse bibt.


Ich hab einfach die Erfahrung gemacht, daß man sich mit "unnötigen" Units, in der Implementation, einige nette und vorallem nicht leicht nachvollziehbare Initialisierungsreihenfolgeprobleme einfangen kann, welches es nicht gäbe, wenn Diese alle im Interface lägen.
$2B or not $2B

Geändert von himitsu (19. Dez 2011 um 09:34 Uhr)
 
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.625 Beiträge
 
Delphi 12 Athens
 
#13

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 09:33
IIRC gab es die "implementation"-uses-Klausel schon unter Delphi 1.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
 
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#14

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 09:36
IIRC gab es die "implementation"-uses-Klausel schon unter Delphi 1.
Worbei Delphi ja nicht der Anfang war.
Lang lebe Turbo Delphi Pascal.

Man könnte ja mal den Herrn Wirth fragen, was er sich dabei dachte.
$2B or not $2B
 
Benutzerbild von uligerhardt
uligerhardt

Registriert seit: 19. Aug 2004
Ort: Hof/Saale
1.746 Beiträge
 
Delphi 2007 Professional
 
#15

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 09:46
Man könnte ja mal den Herrn Wirth fragen, was er sich dabei dachte.
Gar nix - such mal hier nach "unit". Bzgl. seiner späteren Schöpfungen kannst du mal hier schauen. Da war das Modul-Konzept wohl etwas anders als bei Borland.
Uli Gerhardt
 
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#16

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 19:22
Vielleicht gab es ja anfangs nur die obere Uses-Klausel?
Definiere Anfang!

Ich hatte es mir zu TP Zeiten angewöhnt alles ins die Implementation zu packen, da damit ein verstecktes "Durchreichen" von Units vermieden wurde.
In jeder Unit standen also alle benützten Units.
(Ausnahme: im Interface genutzte Units)

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
 
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#17

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 19:48
Wurden in TP Units (deren Deklarationen) denn durchgereicht?

In Delphi machen die das ja nicht.
$2B or not $2B
 
brechi

Registriert seit: 30. Jan 2004
823 Beiträge
 
#18

AW: Uses: Interface vs. Implementation Section

  Alt 19. Dez 2011, 22:53
Packt ihr dann bei einem neuen Formular erstmal alle Units in den Implementationsteil die nicht benötigt werden? Und wenn ihr überprüfen wollt ob eine Unit schon eingebunden ist schaut ihr immer in beiden Uses Bereichen nach? Und Falls dann mal in einem Formular eine Unit im Objekt/Formular benötigt wird kopiert ihr die immer aus dem Implementationsteil in den Interfaceteil? Warum erzeugt Delphi alle benötigten Units immer im Interfacebereich? Fragen über Fragen
Ich mach es wie Himitsu, in den Implementationsbereich kommen nur Units mit Kreuzreferenzen. Darf aber jeder machen wie er will, denke ein "richtig" gibts nicht, es hat beides Vor- und Nachteile.
 
Benutzerbild von sx2008
sx2008

Registriert seit: 16. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#19

AW: Uses: Interface vs. Implementation Section

  Alt 20. Dez 2011, 01:08
Hier sind noch zwei Argumente:
* schaut doch einfach mal nach wie das Uses Thema im Sourcecode der VCL gehandhabt wird.
Sind dort alle benötgten Unit immer im Interface-Abschnitt eingebunden?
Nein? Woran könnte das liegen?

* Man schaue sich mal diese Seite von ModelMakerTools an.
Man sieht, dass es direkte und indirekt benützte Units gibt.
Wenn man Units im Interface-Abschnitt einbindet, dann wird die Abhängigkeit weitergegeben, was man nach Möglichkeit vermeiden sollte.
Der ModelMaker Tools Unit dependency analyzer ist als Standalone Freeware-Anwendung verfügbar. Einfach mal testen...
 
angos

Registriert seit: 26. Mai 2004
Ort: Rheine
549 Beiträge
 
Delphi 11 Alexandria
 
#20

AW: Uses: Interface vs. Implementation Section

  Alt 20. Dez 2011, 07:33
Hauptargument:
* wenn man eine Unit im Implementation-Abschnitt einbindet hilft dies dem Compiler weil er bei Änderung der Unit weniger kompilieren muss und interne Symboltabellen kleiner werden
Bei grossen Projekten mit Hunderten von Units kann das einen grossen Unterschied ausmachen,
denn wenn jede Unit direkt oder indirekt die Symboltabelle jeder anderen Unit benötigt dann ist das ein quadratischer Zusammenhang.
Ok, wenn sich dass tark auf die Geschwindigkeit beim Kompilieren auswirkt, ist das natürlich ein Argument. Das konnte ich bis jetzt noch nicht feststellen, habe allerdings die Software auch auf verschiedene Exen/DLLs verteilt. Der Kompiliervorgang liegt immer unter 5 Sekunden.

Zitat:
Nebenargumente:
* Es gibt in der objekt-orientierten-Programmierung das Prinzip des Information hiding.
Verberge soviel wie möglich von der inneren Struktur.
Mache alles privat mit Ausnahme der Dinge die öffentlich sein müssen.
Das kann man so auch auf die Sichtbarkeitmachung der Abhängigkeiten der verschiedenen Units anwenden
Ja kann man so sehen. Aber es gibt auch das KISS-Prinzip. Ich habe aus diesem Grund die Information lieber an einer Stelle.

Zitat:
* Es gibt z.B. das Freeware Tool Icarus.
Es zeigt nach einer Analyse des Sourcecodes nicht nur unbenützte Units an, sondern zeigt auch die Units, die man vom Interface- in den Implemenation-Abschnitt verschieben kann.
Die Programmierer von Icarus haben sich bestimmt sehr gründlich mit dem Unitkonzept von Delphi auseinandergesetzt und bieten hier bestimmt keine sinnlose Funktion an.
Das es ein Tool dafür gibt, ist kein Grund diese Funktionalität zu nutzen. Durch das Tool habe ich nichts gewonnen. Nur weil jemand etwas tut, muss das nicht richtig sein

Zitat:
Hier sind noch zwei Argumente:
* schaut doch einfach mal nach wie das Uses Thema im Sourcecode der VCL gehandhabt wird.
Sind dort alle benötgten Unit immer im Interface-Abschnitt eingebunden?
Nein? Woran könnte das liegen?
Siehe oben.

Zitat:
* Man schaue sich mal diese Seite von ModelMakerTools an.
Man sieht, dass es direkte und indirekt benützte Units gibt.
Wenn man Units im Interface-Abschnitt einbindet, dann wird die Abhängigkeit weitergegeben, was man nach Möglichkeit vermeiden sollte.
Magst du den dadurch entstehenden Nachteil einmal erläutern?


Und zu vorherigen Posts: Wie schon gesagt wurde, zirkuläre Referenzen als Grund zu nennen, ist ein Kontra-punkt.

Fazit: Aufgrund der Lesbarkeit (alles an einer Stelle ist übersichtlicher) und um gar nicht erst durch einen Fauxpas zirkuläre Referenzen zu implementieren, die ich nachher wieder korrigieren muss, würde ich auch zukünftig weiter alles im interface deklarieren.


Gruß
Ansgar

Geändert von angos (20. Dez 2011 um 07:37 Uhr)
 
Thema geschlossen
Seite 2 von 7     12 34     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:36 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz