Merkwürdiger Source Code? Kann mir das jemand erklären?

[mandoki]

Hallo,
der Titel ist leider nicht sehr aussagekräftig aber ich weiß nicht so recht wie ich das sonst benennen sollte... sorry dafür.

Zu meinem Problem:
Beim testen der Absolute Database Komponente ist mir ein Sourcecode aufgefallen der mich total verwirrt. Es geht hierbei um das Import/Export Tool welches auch im Source-Code beiliegt.

Hier mal einige kurze Ausschnitte (... steht für weiteren Code):

Delphi-Quellcode:

...
function HasVChk(Table: TTable; Field: TField; var VChk: TVChk): boolean;

function ValToStr(VCHK: DBIVCHK; FldType: word): string;
var
  L: longint;
  I: Integer;
  D: Double;
  MyDate: BDE.DBIDATE;
  ...
  ...

und:

Delphi-Quellcode:

...
procedure TImportExportForm.PerformImport;
var
  i, tableCount: Integer;
  tables: TListBox;
  tableName: String;
  PromptOverwrite: Boolean;
  mr: TModalResult;
  Log: String;

procedure AddDefaultMinMaxFieldValues;
var
  VChk: TVChk;
  i: Integer;
  DoRestructureTable: Boolean;
  s: String;
begin
  ABSTable.Open;
  ABSTable.Close;
  ...
  ...

  ...
       Log := Log+s;
     end;
end;

begin
  PromptOverwrite := True;
  IsStopped := False;
  AbsDB.Close;
  ...

  ...
    end;
  end;
end;

var
  Props: CURProps;
  V: VCHKDesc;
  hCur: hDBICur;
  ...

Der Compiler meldet keinen Fehler.
Ist dies einfach nur eine ungewöhnliche (aber erlaubte) Syntax?

(Habe das komplette File für interessierte mal drangehangen...)

[3_of_8]

Das ist weder ungewöhnlich noch merkwürdig. Das ist einfach eine Nested Function, also eine Funktion innerhalb einer anderen Funktion.

[mandoki]

ähm.. ok.. wäre dann das untere beispiel sowas wie nested procedures? :roll:

[Reinhard Kern]

Zitat:

Zitat von mandoki

Hallo,
der Titel ist leider nicht sehr aussagekräftig aber ich weiß nicht so recht wie ich das sonst benennen sollte... sorry dafür.

Zu meinem Problem:
Beim testen der Absolute Database Komponente ist mir ein Sourcecode aufgefallen der mich total verwirrt. Es geht hierbei um das Import/Export Tool welches auch im Source-Code beiliegt.

Hier mal einige kurze Ausschnitte (... steht für weiteren Code):

Delphi-Quellcode:

...
function HasVChk(Table: TTable; Field: TField; var VChk: TVChk): boolean;

function ValToStr(VCHK: DBIVCHK; FldType: word): string;
var
  L: longint;
  I: Integer;
  D: Double;
  MyDate: BDE.DBIDATE;
  ...
  ...

und:

Der Compiler meldet keinen Fehler.
Ist dies einfach nur eine ungewöhnliche (aber erlaubte) Syntax?

(Habe das komplette File für interessierte mal drangehangen...)

Warum sollte er auch, das sind einfach lokale Prozeduren/Funktionen, d.h. ValToStr gilt wie die Variablen nur innerhalb HasVChk (und stört daher nicht, wenn andere Prozeduren ihr eigenes ValToStr haben).

Muster:

Delphi-Quellcode:

procedure Myprocedure;
var dummy : integer;

  procedure MyLocalProcedure;
  var ldummy : integer;
  begin
  end;

begin
MyLocalProcedure;  { geht nur hier von begin bis end }
end;

Natürlich kann eine lokale Prozedur ihrerseits lokale Unterprozeduren haben. Das ist einer der grössten Vorteile von Pascal gegenüber anderen Sprachen und nimmt vieles der Vorteile von OO-Methoden vorweg. Ich benutze das seit 30 Jahren zur Strukturierung von Programmen, aber leider wird das heute aufgrund unverstandener OO-Ideologie abgelehnt oder ist auch überhaupt nicht mehr bekannt - hier im Forum kommen lokale Prozeduren praktisch nicht vor.

Gruss Reinhard

[mandoki]

Hallo Reinhard,

vielen Dank für deine ausführliche Erklärung.
Das mit den Unterprozeduren war mir bisher nicht bekannt.
Ich glaube ich sollte dahingehend noch mal einiges in der Fachliteratur nachlesen... :oops:

Gruß mandoki ;)

[himitsu]

Zu erwähnen sei, daß selbst die nested procedures/functions selber wiederum welche enthalten können.

Und was vorallem wichtig ist, es wird "immer" die letzte Daklaration verwendet ... ist bei Variablen/Typen/Kontanten... genauso.

Delphi-Quellcode:

procedure MyProcedure1;
  begin
    s := IntToStr(123);  // ruft IntToStr aus der Unit SysUtils auf
  end;

function IntToStr(i: integer): integer; // >>IntToStr[1]
  begin
    ...
  end;

procedure MyProcedure2;
  begin
    s := IntToStr(123);   // ruft die IntToStr[1]
  end;

procedure MyProcedure3;
  function IntToStr(i: integer): integer; // >>IntToStr[2]
    begin
      s := IntToStr(123);  // ruft sich selber auf, also IntToStr[2]
    end;

  begin
    s := IntToStr(123);            // ruft ebenfalls IntToStr[2] auf
    s := SysUtils.IntToStr(123);   // ruft IntToStr aus der Unit SysUtils auf
  end;

[mandoki]

Danke für das Beispiel, himitsu.

Da mir die Vorteile aber noch nicht so ganz einleuchteten, hab ich mal gesucht und dieses Thema gefunden. :gruebel:

Gruß mandoki

[negaH]

@Reinhard

Zitat:

aber leider wird das heute aufgrund unverstandener OO-Ideologie abgelehnt oder ist auch überhaupt nicht mehr bekannt - hier im Forum kommen lokale Prozeduren praktisch nicht vor.

Das stimmt so nicht ;) Gerade hier im Forum findet man viele Beispiele mit nested Functions, zumindestens meine Beispiele ;)
Denn, ich stimme absolut mit deiner Meinung überein, es ist ein in Vergessenheit und unterschätztes Feature, das durch masochistische OOP'ler dummerweise auch noch schlecht geredet wird (obwohl es ja das beste Beispiel für Strukturierung, Modularisierung und Sichtbarkeiskontrolle in der MP ist).

Musste ich mal loswerden ;)

Gruß Hagen

[himitsu]

*zustimm*

und außerdem ist es verständlicher überall (da wo es verwendet wird) 'ne eigene nested Function zu hinterlegen, als irgendwo tausende (vielleicht noch überladne) funktion zu deponieren, wo dann keiner mehr weiß wozu die eigentlich noch gehörten.

[Phoenix]

Just my 2 Cents: Ich verwende sowas immer nur sehr Sparsam, bzw. nur an den Stellen, an denen ich mir ziemlich sicher bin, dass ich die Funktion nicht später irgendwo anders doch noch gebrauchen könnte. Denn dann ist meistens Code-Umbauen angesagt und wo im Code umgebaut wird können sich leicht Fehler einschleichen.

[negaH]

Zitat:

Just my 2 Cents: Ich verwende sowas immer nur sehr Sparsam, bzw. nur an den Stellen, an denen ich mir ziemlich sicher bin, dass ich die Funktion nicht später irgendwo anders doch noch gebrauchen könnte. Denn dann ist meistens Code-Umbauen angesagt und wo im Code umgebaut wird können sich leicht Fehler einschleichen.

;) hm , und ich belasse diese Funktion dann als nested Funktion, programmiere sie aber schon von Anfang an so sauber das ich sie eventuell später, bei mehrfacher Verwendung, auslagern kann. Denn exakt so minimiere ich die Komplexität meiner Schnittstellen. Das Schlechteste was man machen kann ist es eine Schnittstelle/Bibliothek/Klasse zu entwicklen die zu komplex wird. Nicht weil sie tatsächlich ein komplexes Problem lösst, sondern einfach weil jeder "Pipelkram" als eigene fast schon sinnlose Funktion/Methode/Komponente extern in der Schnittstelle sichtbar ist. Programmierer die solche Sachen bauen bezeichne ich immer als geschwätzig, viel Source aber nichts wichtiges drinnen, halt meistes OOP-Masochisten, es kommt nur darauf an das man viel schreibt nicht das es sinnvoll ist, Quelltextzeilenjäger ;)

Das ist kontraproduktiv. Leider zb. auch bei Borland mit zb. Unit DateUtils neuderings üblich.
Bei den JEDIs gabs mal ein Derivat eines TLabel das ein HTML Link aufrief. Der essentiell wichtgste Teil dieser ganzen Unit mit 50 Zeilen Quelltext war das:

Delphi-Quellcode:

ShellExecute(Caption); // Caption == [url]http://www.url[/url]

Anders Beispiel:

Properties in Interfaces ?!??!!
Was soll das bitte schön ? Ein Interface ist eine vollkommen public Schnittstelle. Zugriffsmethoden -> Setter und Getter von Properties sind immer protected/private Schnittstellen. Eine Property in einem Interface benötigt Zugriffsmethoden, äh ?

Interface == public <> Property == protected/private

Das Konzept der Interfaces und die Art und Weise wie man in Delphi Properties deklariert widersprechen sich konzeptionell.

Also entweder in Interfaces
1.) keine Properties mit privaten/protected Setter/Getter Methoden, oder
2.) Borland muß die Sprachfeatures ändern damit man auch in Interfaces protected/private Methoden deklarieren kann

Da 2.) aber dem anerkannten Interface Konzpet widerspricht und Borland es nicht ändern kann ohne inkompatibel mit zb. COM/DCOM/ActiveX zu werden bleibt uns nur Lösung 1.) übrig.

In Interfaces haben Properties nichts zu suchen da diese immer Getter/Setter Methoden benötigen die ansich immer protected oder privat sein müssten, aber in Interface nicht sein können.

Also jeder Programmierer der in Interfaces Properties benutzt überfrachtet seine Schnittstelle mit überflüssigen Möglichkeiten, denn die Property stellt nicht mehr den einzigsten Zugriffsweg im Interface dar, man kann ja auch die public sichtbaren Setter/Getter gleich direkt benutzen.
Das ist so als hätte eine Machine gleich 2 Notausschalter (aber unterschiedlich benamt und eingefärbt), der Bediener fragt sich dann immer welchen er benutzen soll wenn es brenzlig ist, na toll und er liest erstmal das 1000 Seiten Handbuch ;)

Gruß Hagen

[Elvis]

Zitat:

Zitat von negaH

Denn, ich stimme absolut mit deiner Meinung überein, es ist ein in Vergessenheit und unterschätztes Feature, das durch masochistische OOP'ler dummerweise auch noch schlecht geredet wird (obwohl es ja das beste Beispiel für Strukturierung, Modularisierung und Sichtbarkeiskontrolle in der MP ist).

Ich bin nicht masochistisch, also musst du wohl Phoenix gemeint haben. :mrgreen:

Ich finde nested functions ziemlich cool. Man kann damit einige Dinge einfach lesbarer gestalten, oder auch Code, der doppelt in einer Prozedur vorkommt, nur noch an einer Stelle zu haben.
Da man Zugriff auf alle lokalen Variablen hat, muss man auch nicht einen Rattenschwanz an Parametern mitschleppen. :)

[glkgereon]

Ich muss Phoenix leider recht geben :-)

Ich weiss leider im vorneherein nicht immer so genau wo ich das eventuell nochmal brauchen könnte, und dann kommts erstmal in Private rein...
Und auch zum Interface: Ich weiss nicht so genau wann ich was von wo mal aufrufen will....
Ich als Hobby-Programmierer setze ja keinen festen Code um (ka wie ich das beschreiben soll) sonderen "Das Programm wuchs in mir" oder so ähnlich (Hr Tolkien würde sich im Grabe umdrehen :-D )
Insofern kommen procedures von denen ich nicht 100%ig weiss, das sie niemanden ausser dieser klasse etwas angehen, nach Public.

(Und meisstens bin ich nachher zu faul es wieder umzubauen :wall: wobei eigentlich kein Programm wirklich fertig geworden ist bisher... es funktioniert und ich benutze es, aber es gibt immer was was ich eigentlich noch ändern/erweitern/bugfixen wollte...)

[himitsu]

Zitat:

Zitat von Elvis

Da man Zugriff auf alle lokalen Variablen hat, muss man auch nicht einen Rattenschwanz an Parametern mitschleppen. :)

*nicht zustimm*

Delphi-Quellcode:

Procedure Mama(Familie: TGesellschaft);
  Var Muttermilch: TFunktion;

  Procedure Kind;
    Begin
      Familie.AllesTerrorisieren;
      Muttermilch.Besaufen;
      Liebe.Bekommen;  // <<< geht nicht !!!
    End;

  Var Liebe: TGefuehle;

  Begin
    Familie.Angstmodus.Aktivieren;
    Muttermilch.Ausschenken;
    Liebe.Abschalten;
    Kind;
  End;

[Kedariodakon]

Zitat:

Zitat von negaH

...
Properties in Interfaces ?!??!!
Was soll das bitte schön ? Ein Interface ist eine vollkommen public Schnittstelle.
...

Ich schrieb schonmal was dazu, diese Propertys seh ich als sehr hilfreich an, zwar hat man im Interface eine Zeile mehr, aber dafür hat man an anderer Stelle bedeutent weniger Schreibkram und kann "schöner" mit dem Interface arbeiten...
Und Delphi ist sogar so schlau und versteckt bei Propertys auch die Getter und Setter Methoden bei Interfaces, wenn sie in Propertys benutzt werden, wodurch sie nach außen (zumindest in Delphi) auch erstmal nicht zu sehen sind...
Schlussendlich wird der Code dadürch auch übersichtlicher...
Ich find es sogar echt schade, dass man generell keine Propertys in C++ oder C# hat...
Diese dienen ja vorallem der Übersicht, vor allem bei der Anwendung...

Bye Christian

[negaH]

Zitat:

Ich weiss leider im vorneherein nicht immer so genau wo ich das eventuell nochmal brauchen könnte, und dann kommts erstmal in Private rein...
Und auch zum Interface: Ich weiss nicht so genau wann ich was von wo mal aufrufen will....

Hallooooo ? Was programmierst du da eigentlich ? (sorry für mein Sarkasmus ;) )

Es ist eine Schnittstelle und das Ziel jeder Schnittstelle ist es einem anderen Programmierer mitzuteilen was man machen kann um ein Gesamtproblem mit dem sich diese Schnittstelle befasst lösen zu können. Nicht was man noch so alles manchen kann oder wie man was intern gelösst hat.

Also die Frage "ich weis nicht was ich aufrufen könnte in Zukunft" ist haarscharf am Arbeitsthema eines Schnittstellenprogrammierers vorbei. Denn es ist die Aufgabe eines solchen Typens eben exakt die Zukunft zu planen. Eine Schnittstelle plant also exakt das was man zur Problemlösung in Zukunt benutzen können soll. Ergo: die wichtigste Vorraussetzung bei einer Schnittstelle ist das der Programnmierer schon für die Zukunft geplant hat, anders ausgedrückt der Typ weis ganz genau was man in Zukunft braucht.

So, soweit erstmal zu dem worauf sich meine obigen Postings bezogen. Nun zur "menschlichen" Seite des Problems ;) Ja, ich kenne das Gefühl wie jeder andere Entwicjler auch manchmal blind sein zu müssen. Man weis eben nicht was man irgendwan nochj in der Zukunt benötigen könnte. Und exakt aus diesem Grunde sind auch nested Funktionen idel. Denn sie sind absolut unsichtbar in der Schnittstelle abr können in Zukunft wenn man sie nochmal benötigt sehr einfach

1.) kopiert werden wenn die Kopie wiederum nur privat sein soll
2.) in die Schnittstelle exportiert werden, also publiziert werden

Besser als sie schon von vornherein als überflüssigen Ballast in der Schnittstelle zu veröffentlichen der

1.) nur Verwirrung stifftet
2.) zu 99% niemals wieder benötigt wird
3.) zusätzlich gewartet werden muß, Dokumentation/Helpfiles etc.
4.) im Grunde immer ein Spezialproblem löst und aus dem Zusammenhang gerissen wurde

Gruß Hagen

[negaH]

Delphi-Quellcode:

Procedure Mama(Familie: TGesellschaft);
  Var Muttermilch: TFunktion;

  Procedure Kind;
    Begin
      Familie.AllesTerrorisieren;
      Muttermilch.Besaufen;
      Liebe.Bekommen;  // <<< geht nicht !!!
    End;

  Var Liebe: TGefuehle;

  Begin
    Familie.Angstmodus.Aktivieren;
    Muttermilch.Ausschenken;
    Liebe.Abschalten;
    Kind;
  End;

Na ist doch ein ideales Beipsiel !! ;)
Du hast Liebe als Variable erst NACH procedure Kind deklariert, ergo wolltest du auch das procedure Kind keinen Zugriff darauf bekommen darf. Denn du willst ja Fehler vermeiden oder ? Du kompilierst es und stellst fest geht nicht, ups, darf Kind Liebe benutzen, nein? gut eine Fehler, ja? machtnichts schreiben wirs um

Delphi-Quellcode:

procedure Mama(Familie: TGesellschaft);
var 
  Muttermilch: TFunktion;
  Liebe: TGefuehle;

  procedure Kind;
  Begin
    Familie.AllesTerrorisieren;
    Muttermilch.Besaufen;
    Liebe.Bekommen;  // <<< geht doch !!!
  end;


begin
  Familie.Angstmodus.Aktivieren;
  Muttermilch.Ausschenken;
  Liebe.Abschalten;
  Kind;
end;

Gruß hagen

[negaH]

Zitat:

Ich schrieb schonmal was dazu, diese Propertys seh ich als sehr hilfreich an, zwar hat man im Interface eine Zeile mehr, aber dafür hat man an anderer Stelle bedeutent weniger Schreibkram und kann "schöner" mit dem Interface arbeiten...
Und Delphi ist sogar so schlau und versteckt bei Propertys auch die Getter und Setter Methoden bei Interfaces, wenn sie in Propertys benutzt werden, wodurch sie nach außen (zumindest in Delphi) auch erstmal nicht zu sehen sind...

Auch wenn Delphi "clever" ist, ich bezeichne dies als Augenwischerei, verdeckt es damit doch eine konzeptionelle Fehlentwicklung.
Interfaces sind per Definition vollständig sichtbare abrstrakte Deklarationen einer Schnittstelle, deshalb heisen sie ja Interface !
Eoin Interface sagt nichts daraüber aus WER, WIE, WO, WAS tatsächluch implentiert, und das ist ihr Bestimmungszweck ihre Konzeption.
Damit gehören in Interfaces niemals Implementierungdetails rein und eine Geter/Setter Methode für eine Property IST implementierend.

Ein Interface wird programmiert für Andere, und nicht für dich (aus Sicht des Sources betrachtet).

Zitat:

Schlussendlich wird der Code dadürch auch übersichtlicher...

Egoist ;) Du programmierst eine Schnittstelle die andere benutzen sollen und du betrachtest nur deinen sauberen Code. Das ist nicht zielorientiert.

Gruß Hagen

[Kedariodakon]

Da magst du im Grunde Recht haben, aber wenn ein Interface dadurch einfacher zu benutzen ist und übersichtlicher ist, dann ist doch beiden geholfen, es verliert dadurch ja nicht an Funktionalität... :gruebel:

Vielleicht seh ich das einfach nicht so eng wie du :stupid:

Bye Christian

[Phoenix]

Zitat:

Zitat von Kedariodakon

Da magst du im Grunde Recht haben, aber wenn ein Interface dadurch einfacher zu benutzen ist und übersichtlicher ist, dann ist doch beiden geholfen, es verliert dadurch ja nicht an Funktionalität... :gruebel:

Stell Dir ein Team vor:

Einer designed die Anwendung (und damit die Interfaces).
4 andere Implementieren die Interfaces (ggf. unterschiedlich für verschiedene Zwecke).
5 andere Konsumieren diese Interfaces (ggf. mehrfach).

Und nun gibt der Architekt den Leuten die die Interfaces implementieren sollen die implementierung der Properties vor. Mindestens 3 von den Entwicklern werden fluchen.

[negaH]

Das wird so sein ;)

Aber betrachte es mal aus Sicht einer "Arbeitsorganisation" oder aus Sicht einer "Teamarbeit". Der Source soll nicht Selbstbefriedignung sein, also kein Selbstzweck sondern verfolgt eine klare Zielsetzung um ein Problem zu lösen. Jede zusätzliche und nicht notwendige Information in der Schnittstelle zum Source erhöht den Arbeitsaufand für diejenigen die diesen benutzen müssen. Also mehr an Dokumentation, mehr zum Lernen, weniger Zielorientierung, höhere Fehleranfälligkeit sprich Fehlbenutzungen weil die Schnittstelle verwaschen, also unklar ist. Das Geheimnis liegt in der Restriktion, man beschränkt sich auf notwendige Grundfunktionen, bekommt so eine Standardisierung hin und schwups wird die spätere Benutzung stark ökonomisiert. Das ist doch recht simpel einzusehen da wir als Menschen doch in allen Bereichen nach diesem Muster vorgehen, oder ?

PASCAL ist viel restriktiver als C zb. und exakt deshalb lieben wir es doch auch. Restriktiver heist eben nicht weniger Universalität sondern mehr, da eine sauber durchdachte Schnittstelle wie ein Baukastensystem viel variantenreicher sein wird.

Hm, sowas kann man eigentlich nur Auge in Auge diskutieren. Auf alle Fälle programmiere ich schon ziemlich lange professionell und meistens in Teams, ich kann nur aus meiner Erfahrung erzählen.

Gruß Hagen

[negaH]

Zitat:

Und nun gibt der Architekt den Leuten die die Interfaces implementieren sollen die implementierung der Properties vor. Mindestens 3 von den Entwicklern werden fluchen.

Viel schlimmer ;(

Da der Architekt unantastbar ist werden diese 3 garnichts sagen, ja sie fluchen im Bestfall jeder für sich, im schlechtesten Falle bilden sie eine versteckte Front gegen den Architekten. Aber konstruktiv wird es meistens nie. Auf alle Fälle sinkt die innere Motivation im Team. Denn die Hauptursachen für verwaschene Interfaces, für ellenlange Source mit wenig Nutzen sind

- Profilierungssucht
- Egosimus
- Selbstüberschätzung

Dabei habe ich die Erfahrung gemacht das gut durchdachte und einfach gehalten Schnittstellen das Gegenteil bewirken. Hat also der Architekt seine Aufbae gut gemacht so werden die Leute zusätzlich motiviert, sie machen weniger Fehler, man arbeitet effizienter und auch effektiver.

Mal ehrlich, wir alle arbeiten doch lieber mit Komponneten etc.pp. die exakt das machen was wir benötigen und das auch noch effizent und korrekt. Grausig sind doch die Kompenenten die tausende Properties haben die versprechen alles zu können und dann im Detail doch immer nur die Hälte ermöglichen.

Gruß Hagen

[Kedariodakon]

Hä :gruebel:

Die Propertys sind doch nur Show, die müssen doch im zu implementierenden Object gar nicht vorhanden sein...
Die sind nur fürs Interface...

Und dort werden sie eindeutig durch die Set-/Get-Funktionen festgelegt...
Nunja, jeder hat halt seine Meinung zu diesem Thema, wie dem auch sein, ich Egoist find sie praktisch :stupid:

Bye Christian

[himitsu]

Zitat:

Zitat von negaH

Na ist doch ein ideales Beipsiel !! ;)
Du hast Liebe als Variable erst NACH procedure Kind deklariert, ergo wolltest du auch das procedure Kind keinen Zugriff darauf bekommen darf. Denn du willst ja Fehler vermeiden oder ? Du kompilierst es und stellst fest geht nicht, ups, darf Kind Liebe benutzen, nein? gut eine Fehler, ja? machtnichts schreiben wirs um

joo, es war ja nur weil da vorne wer meinte man habe auf alle lokalen Variablen Zugriff ... und dem ist ja nicht so ^^

[mandoki]

Uff.. da hab ich ja ne heisse Diskussion losgetreten.

Vielleicht sollte man den Titel umbenennen in:
Diskussion zum Thema: Nested Functions/Procedures :zwinker:

Ist auf jeden Fall sehr interessant und lehrreich, die verschiedenen Meinungen zum Thema. :thumb:

Gruß mandoki

[negaH]

Zitat:

Die Propertys sind doch nur Show, die müssen doch im zu implementierenden Object gar nicht vorhanden sein...
Die sind nur fürs Interface...

Ja, und das ist ja gerade das Problem von dem ich rede. Die Getter/Setter Methode einer Property in einem Interface sind ebenso öffentlich sichtbar wie die Property selber. In einem Interface gelten 2 goldende Regeln

1.) alles ist öffentlich -> logisch ist ja ein abstraktes Modell so ein Interface
- keine differenzierte Sichtbarkeitsregeln, es gibt also kein private/protected/public etc.pp
- somit alles public

2.) ein Interface sollte niemals Aussagen über die reale Implementierung treffen -> also vollständig abstrakt
- ein Interface kann durch verschiedene impelementierende Klassen benutzt werden
- ein Interface kann sogar über mehrere Klassen implementiert werden, dh. gleich mehrere Klassen stellen die reale Impelementierung des Interfaces dar
- die reale Implementierung eines Interfaces kann durch den Implementor weiter delegiert werden
- die Lebenszeit der implementierenden Klassen eines Interfaces ist undefiniert, großer Unterschied zu Klassen
- ein Interfaces muß garnicht durch eine Klasse implementiert werden, es geht auch procedural oder sonstwie, eben weil das Interface keinerlei Aussagen trifft was, wann, wo, wie und womit real implementiert ist
- ein Interface kann nur eine Teilmenge der Funktionalität einer komplexen Klasse exportieren, also Reduktion der verfügbaren Funktionalität einer Klasse nach aussen und das sogar noch auf eine Art&Weise das man eben nicht wissen kann wie es impelmentiert wurde, also abstrakt. Das heist man kann über Interfaces quasi zu einer bestehenden Klassenhierarchie eine komplett umstrukturierte und unabhängige Parallel-Hierarchie aufbauen, einfach nur durch reine Deklarationen. So gesehen sind Interfaces sowas wie ein Translator von Denkmodellen, sie translieren von einem Denkmodell einer Klassenstruktur in Programmierspache A in ein komplett anderes Denkmodell in Sprache B. Und das war die Ursache dafür das es überhaupt Interfaces heutzutage gibt.

Das alles sind ja gerade die Vorteile der Interfaces.
Man kann sich diese verbauen wenn man dieses gute Konzept aufweicht, eben bei Properties in Interfaces.
Getter/Setter Methoden einer Property gehören zur Klasse der implementierenden Methoden, sie sind nicht abstrakt noch losgelösst sondern implementieren konkret die Funktionalität zu einer deklarierten Property, ergo sie exportieren Delphitypische Sprachkonstrukte. Damit widersprechen sie dem Konzept der vollkommenen Abstraktion die Interfaces erreichen sollen.

Klar soweit ?

Gruß Hagen

[negaH]

Zitat:

joo, es war ja nur weil da vorne wer meinte man habe auf alle lokalen Variablen Zugriff ... und dem ist ja nicht so ^^

Ich weis ;) es ist aber ein gutes Beispiel an dem man zeigen kann was "Sichtbarkeit" bedeutet und wie man es als Instrument für besseren Sourcecode aktiv einsetzt. Man deklariert also nur diejenigen Variablen vor einer Funktion die diese auch nutzen darf. So verhindert man planmäßig Fehler.

Und um "Sichtbarkeit" als Instrument für guten Sourcecode gehts hier in der Diskussion:

Sichtbarkeit bei:

- Funktionen, sprich "nested Functions" als die am unsichtbarsten modularen Konsrukte der MP
- Interfaces und die Sichtbarkeit von nicht abstrakten Getter/Setter Methoden durch die Verwendung von Proprties in der OOP

Gruß hagen

[negaH]

Wenn ich die Properties bei Interfaces entwickeln sollte dann so:

Delphi-Quellcode:

type
  IMyInterface = interface
    function XYZ: HResult;

    property Name: INameProperty; 
  end;

  INameProperty = interface(IAbstractProperty)
    function Getter: Variant; default;
    function Setter(Variant); default;
  end;

Dh. im IMyInterface wird keinerlei Aussage darüber getroffen wie die Property Name real zu implementieren ist. Es seht nur der Typ der Property drinnen und selbst dieser könnte abstrakt sein, sprich Variant.

Das implementieren Property Interface könnte nun separat impelemntiert werden oder auch gleich von der selben Klasse die auch IMyInterface impleentiert. Auf alle Fälle ist alles abstrakt deklariert im Interface und um Abstraktion geht ja dabei.

Es gibt aber schon andere Wege über TypeLibs, dispatchable Interfaces IDispatch und den ganzen Kram. Damit versucht man im Grunde exakt das zu machen. Dh. es gibt schon klare Standards wie man eine Property über dispid und TypeLibs in ein Interface deklariert. Das unterscheidet sich natürlich vom Delphi Property Konzept.

Gruß Hagen