Interface richtig verstanden?

[stahli]

Oh, zu viel der Ehre. Aber Danke.

In Deinem Projekt sind mir beim schnellen drauf schauen ein paar Dinge aufgefallen:

- OnCreate wird nicht aufgerufen. Die Ereignisbehandlung ist nicht richtig zugewiesen. (Musst Du mal zuweisen und einen Haltepunkt setzen.)
- Die Methoden Fahr und Flieg und Schwimm rufen sich selbst auf. Das führt zu einem Stack Overflow.
- Deine Klassen leitest Du manchmal von TInterfacedObject ab und manchmal von einer eigenen Basisklasse. Das ist nicht falsch, aber man muss sich immer genau überlegen, von was man ableitet, damit das dann zur Geschäftslogik passt.
- Supports kann noch mehr. Man kann eine eigene Variable dafür benutzen. Ich mache gern das so weil es m.E. übersichtlicher ist:

Delphi-Quellcode:

var
  lSchwimm: ISchwimm;
…
  if Supports(I, ISchwimm, lSchwimm) then
    lSchwimm.Schwimm;

Ich hoffe, das hilft noch etwas weiter...

[Rudy Velthuis]

Zitat von stahli:

Delphi-Quellcode:

var
  lSchwimm: ISchwimm;

Echt jetzt, lSchwimm und ISchwimm? Die sind ja kaum auseinander zu halten!

Dann schreibe doch wenigstens LSchwimm. Das ist besser lesbar.

[stahli]

"l" für lokal
Ich komme damit klar.

[Dennis07]

Zitat von stahli:

"l" für lokal
Ich komme damit klar.

Mag sein, ist aber weder besonders zweckmäßig, noch konform mit den allgemeinen Style-Guidelines.

[Rudy Velthuis]

Zitat von stahli:

"l" für lokal
Ich komme damit klar.

"L" wäre auch für lokal und lesbar.

Und man schreibt nicht nur für sich selbst. Code sollte lesbar sein, damit auch andere ihn lesen können (oder du selbst, z.B. nach 6 Monaten).
Vor allem Code, den du ausdrücklich für andere schreibst (wie hier).

"Ich komme damit klar" ist sowas wie "auf meinem Rechner läuft's".

[EdAdvokat]

Hinweise 1-3 aus #11 habe ich abgeändert.
Den letzten Stabstrich verstehe ich nicht:

Zitat:

- Supports kann noch mehr. Man kann eine eigene Variable dafür benutzen. Ich mache gern das so weil es m.E. übersichtlicher ist:
markieren

Delphi-Quellcode:

var
  lSchwimm: ISchwimm;
…
  if Supports(I, ISchwimm, lSchwimm) then
    lSchwimm.Schwimm;

Sicher muss ich auch noch nicht alles verstehen, doch die ganze Sache hat mich in Fragen Interfaces doch ein kleines Stück weiter gebracht.
Nochmals Danke an alle Mitwirkenden

[stahli]

Supports weist einfach das Ergebnis gleich der Variablen zu, mehr ist da gar nicht... (also intern wird sowas wie lSchwimm := (I as ISchwimm) gemacht)
Wenn Support False liefert, enthält die Variable NIL.

Das macht die Verwendung von Supports etwas übersichtlicher.

[TurboMagic]

Zitat von stahli:

"l" für lokal
Ich komme damit klar.

Das mag sein, aber hier muss ich mal doch Rudy zustimmen!
Man kann da sehr leicht was verwechseln...

[Schokohase]

Damit es auch jeder versteht:

Das Problem ist, dass Klein-Ludwig fast genauso aussieht wie Groß-Ida. Ja es ist abhängig vom Font.

Zitat:

l vs I

Zumal man im Allgemeinen in Delphi die PascalCase Schreibweise für Variablen-Namen bevorzugt und nicht wie z.B. bei C# camelCase. Und bei PascalCase wird der erste Buchstabe immer groß geschrieben.

Warum das jetzt wohl PascalCase heißt und wo das historisch herkommt darüber darf ein jeder still vor sich hin sinnieren.

Das Problem ist also nicht das L sondern nur die Schreibweise als Kleinbuchstabe.

[EdAdvokat]

Ich komme nochmals auf das Projekt von Stahli zurück.
TVogel hat das Interface IFlieg und die diesem eigene procedure Flieg.
TStorch wurde von TVogel abgeleitet. Also sollte doch auch TStorch, ebenso wie TAdler auch die das Interface IFlieg
besitzen, doch weder TStorch noch TAdler haben die von IFlieg verlangte procedure Flieg.
Bisher bin ich davon ausgegangen, dass die abgeleiteten Klassen (TStorch und TAdler) sowohl die Eigenschaften der
Basisklasse (TVogel) als auch das dem TVogel zugeordnete Interfache IFlieg ebenso wie das TInterfacedObject erben.
Hab ich das ganze noch nicht richtig verstanden?