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

[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:

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 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.

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 )
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 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 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 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...

Vielleicht seh ich das einfach nicht so eng wie du

Bye Christian

[Phoenix]

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...

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.