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