Variablen-Übergabe zwischen zwei Units

[Fritzew]

Zitat:

Zitat von mjustin (Beitrag 1374619)

Zwei Parameter sind zu viel :)

Delphi-Quellcode:

type
  IKunde = interface
  ...
  
function LeseDaten(const KundenNummer: string): IKunde;

Kommt darauf an wer nachher für die Daten verantwortlich ist. Der Aufrufende oder der Aufrufen...

Ich würde das so machen:
Kunde muss vorher initialisiert sein:

Delphi-Quellcode:

function LeseDaten(const KundenNummer: string; Value : IKunde): boolean;

Kann ich dann einfach in Code benutzen mit

if LeseDaten('1000', localKunde) then
begin
end

oder auch

Delphi-Quellcode:

function LeseDaten(const KundenNummer: string; var Value : IKunde): boolean;

[mjustin]

Zitat:

Zitat von Fritzew (Beitrag 1374620)

Delphi-Quellcode:

function LeseDaten(const KundenNummer: string; var Value : IKunde): boolean;

Das var ist nicht notwendig, man kann auch über const Value: IKunde ein existierendes (leeres) Kundenobjekt übergeben, füllen, und an den Aufrufer zurückgeben. Warum sollte man erst ein Objekt erzeugen, es per var übergeben, und in der aufgerufen Methode LeseDaten dann ein neues Objekt erzeugen, und das übergebene Objekt durch es ersetzen?

[SneakyBagels]

Zitat:

gute Idee - aber ... für mich ist das zu hoch

Da stimme ich dir zu. Wie es aussieht, bist du rein hobbymäßig mit Delphi unterwegs. Da braucht man so hohen Kram nicht.

Nimm Records und damit hat sich das!
- einfach zu erstellen
- einfach zu erweitern
- relativ wenig Code
- verständlich

[Fritzew]

Zitat:

Zitat von mjustin (Beitrag 1374622)

Zitat:

Zitat von Fritzew (Beitrag 1374620)

Delphi-Quellcode:

function LeseDaten(const KundenNummer: string; var Value : IKunde): boolean;

Das var ist nicht notwendig, man kann auch über const Value: IKunde ein existierendes (leeres) Kundenobjekt übergeben, füllen, und an den Aufrufer zurückgeben. Warum sollte man erst ein Objekt erzeugen, es per var übergeben, und in der aufgerufen Methode LeseDaten dann ein neues Objekt erzeugen, und das übergebene Objekt durch es ersetzen?

Ja es ging mit ja nur darum die verschiedenen Möglichkeiten zu zeigen. Const in Interface Parametern würde ich aber nur dann verwenden wenn es wirklich zeitkritischer Code ist. Da man dadurch die Referenzzählung aushebelt kannn das teilweise zu unschönen Effekten führen. (Ist aber ein komplett anderes Thema ;-))
Was ich in Delphi wirklich vermisse ist die Möglichkeit wie in C++ Zuweisungen auszuwerten also z.B (Wunschdenken)

Delphi-Quellcode:

if (myKunde := GetKunde('1000')) <> nil then ...

Man darf ja noch träumen oder? :-)

[Fritzew]

Zitat:

Zitat von SneakyBagels (Beitrag 1374623)

Zitat:

gute Idee - aber ... für mich ist das zu hoch

Da stimme ich dir zu. Wie es aussieht, bist du rein hobbymäßig mit Delphi unterwegs. Da braucht man so hohen Kram nicht.

Nimm Records und damit hat sich das!
- einfach zu erstellen
- einfach zu erweitern
- relativ wenig Code
- verständlich

Entschuldige aber so eine Aussage ist einfach ....

Du benutzt Interfaces (Schnittstellen ) täglich mehrfach. Was ist ein Stromstecker? Interessiert es die Strombuchse ob da ein Toster
oder ein Drucker daran hängt? Ne die 2 wissen nur das sie zusammengesteckt werden können, 2 Leitungen fertig. Was dahinterhängt ist egal. Und genau das ist ein Interface. Warum auch immer das nicht immer alle abstrahieren können ist mir zu hoch.
Aber bitte lasse Aussagen wie hohen Kram einfach sein. Danke

[mjustin]

Zitat:

Zitat von Fritzew (Beitrag 1374625)

Const in Interface Parametern würde ich aber nur dann verwenden wenn es wirklich zeitkritischer Code ist. Da man dadurch die Referenzzählung aushebelt kannn das teilweise zu unschönen Effekten führen.

Die Referenzzählung wird dadurch nicht ausgehebelt sondern nur eine unnötige zusätzliche Referenzzählung vermieden. Ist also eine Optimierung.

Nur das hier darf man dann nicht: LadeDaten(TKunde.Create);

Dass dann die Referenzzählung nicht funktioniert, ist ein lang und gut bekannter Bug. (https://stackoverflow.com/a/7640979/80901)

[Fritzew]

Ja genau deshalb der Hinweis auf zeitkritischer Code:

Zitat:

Zitat von mjustin (Beitrag 1374629)

Zitat:

Zitat von Fritzew (Beitrag 1374625)

Const in Interface Parametern würde ich aber nur dann verwenden wenn es wirklich zeitkritischer Code ist. Da man dadurch die Referenzzählung aushebelt kannn das teilweise zu unschönen Effekten führen.

Die Referenzzählung wird dadurch nicht ausgehebelt sondern nur eine unnötige zusätzliche Referenzzählung vermieden. Ist also eine Optimierung.

Nur das hier darf man dann nicht: LadeDaten(TKunde.Create);

Dass dann die Referenzzählung nicht funktioniert, ist ein lang und gut bekannter Bug. (https://stackoverflow.com/a/7640979/80901)

Da man nie weis wie der Code benutzt wird... Optimierten nur dann wenn wirklich notwendig

[Fritzew]

Zitat:

Dass dann die Referenzzählung nicht funktioniert, ist ein lang und gut bekannter Bug. (https://stackoverflow.com/a/7640979/80901)

Nachtrag: Laut Embarcadero ist das kein Bug, (as designed) ;-)

[mjustin]

Zitat:

Zitat von Fritzew (Beitrag 1374631)

Zitat:

Dass dann die Referenzzählung nicht funktioniert, ist ein lang und gut bekannter Bug. (https://stackoverflow.com/a/7640979/80901)

Nachtrag: Laut Embarcadero ist das kein Bug, (as designed) ;-)

;-)

"as designed" ist eine Umschreibung für "wir müssten Teile des DCC neu designen, um diesen Effekt zu vermeiden" (wenn ich Remy Lebaus Kommentar richtig verstehe). Bei strings tritt das Problem nicht auf, DCC erzeugt für diese eine versteckte Variable.

[SneakyBagels]

Zitat:

Was dahinterhängt ist egal.

Im Gegensatz zu einer Steckdose muss man das in Delphi aber selber implementieren und im besten Falle auch verstehen.

Es gibt Leute die wollen keine Interfaces nutzen, fertig aus Ende der Geschichte.
Außerdem sind wir schon meilenweit von der Ausgangsfrage entfernt.

Der TE fragte, welche der von ihm DREI vorgestellten Möglichkeiten die beste ist. Interfaces standen nicht auf seiner Liste.
Ich verstehe nicht, wie man sich nie an die von den Themenerstellern gewünschten Codes halten kann und immer Gift (Interfaces) einfügen muss, was dann früher oder später wieder zu einem geschlossenen Thread führt.

Daher: bitte bleiben wir doch einfach bei den vom TE genannten Möglichkeiten.