verschachtelte function?

**xaromz**

Hallo,

Zitat von SirThornberry:

@xaromz: Was spricht in deinem Fall dagegen die Funktionen als eigenständige Funktionen zu Handhaben?

Die vielen lokalen Variablen, von denen ich oben schrieb. Außerdem finde ich die lokale Sichtbarkeit den Funktionen irgendwie logischer, da es sich ja um "Unterstützungsfunktionen" der Hauptfunktion handelt, die nur im Kontext dieser sinvoll sind. Wozu also auslagern?

Gruß
xaromz

**Der_Unwissende**

Zitat von xaromz:

Hallo,
Leider sind aber nicht alle Aufgaben so einfach, dass sie sich in drei Zeilen abhandeln lassen.

Dann nimm doch 4 Zeilen

Nein, mal ganz ehrlich, wozu ist denn so etwas wie Objekt Orientierung gut? Soweit ich weiß ist das eine Möglichkeit Programme die etwas mehr als 3 Zeilen haben sinnvoll zu strukturieren. Wie gut jmd. diese gegebene Möglichkeit nutzt ist natürlich etwas anderes.
Übersichtlich finde ich (ist nur eine Meinung) die lokalen Funktionen gar nicht. Zwar kann ich hier auf Variablen zugreifen, aber wenn ich eine 500 Zeilen Funktion (mit all ihren lokalen Funktionen zusammen) habe und 20 Parameter, dann frage ich mich warum das keine eigene Klasse ist. Natürlich kann man nicht pauschal sagen > 5 Zeilen = Klasse draus machen, aber eigene Problematik gelöst = Klasse draus machen schon!
Deswegen sorry, muss ich RavenIV zustimmen, dass du eventuell einfach nur ungeeignet designst. Ich denke es gibt andere Sprachen, die keine Lokalen Funktionen erlauben (auch keine Makros oder ähnliches) die auch übersichtlichen Code hinbekommen (mit > 3 Zeilen).

Gruß Der Unwissende

[EDIT]

Zitat von xaromz:

Die vielen lokalen Variablen, von denen ich oben schrieb. Außerdem finde ich die lokale Sichtbarkeit den Funktionen irgendwie logischer, da es sich ja um "Unterstützungsfunktionen" der Hauptfunktion handelt, die nur im Kontext dieser sinvoll sind. Wozu also auslagern?

UPS, wo kommt das denn her? Na ja, dann auch dazu noch was

Na ja, wenn du ein Problem löst (und es auch noch eine gewisse Komplexität übersteigt), dann lohnt sich auslagern immer. Du hast deine Methode und ihre Implementierung nach eigener Aussage mehrfach verändert. Das kannst du natürlich noch viel leichter mit einem Objekt machen. Du kannst hier einfach neue Klassen schaffen (mit gleicher Schnittstelle) und die beliebig austauschen und das alles als Basis für weitere Spezialisierungen verwenden. Taucht dein Problem noch einmal auf, kannst du einfach die Klasse (die hier die ausgelagerte Funktion ist) verwenden.
Ich denke es wäre auch lesbarer, da sich alle Prozeduren immer auf einer Ebene befinden. Vorallem sehen Leute die nicht häufig (oder nie) mit lokalen Prozeduren arbeiten sofort wo Anfang und Ende einer Prozedur stehen.
[/EDIT]

**RavenIV**

Wenn man sich der Namensgebung ein wenig widmet, kann man das Logische auch recht gut abbilden.

markieren

Delphi-Quellcode:

			function Rechnen ();

function Rechnen_BerechneWas ();

function Rechnen_HoleWerte ();

function Rechnen_WerteAusgeben ();

usw.

Da sieht man doch auch auf einen Blick, was zusammen gehört.

**SirThornberry**

Zitat von xaromz:

Hallo,

Zitat von SirThornberry:

@xaromz: Was spricht in deinem Fall dagegen die Funktionen als eigenständige Funktionen zu Handhaben?

Die vielen lokalen Variablen, von denen ich oben schrieb. Außerdem finde ich die lokale Sichtbarkeit den Funktionen irgendwie logischer, da es sich ja um "Unterstützungsfunktionen" der Hauptfunktion handelt, die nur im Kontext dieser sinvoll sind. Wozu also auslagern?

Gruß
xaromz

Ist es da aber nicht sinnvoller die Funkion zu einer Klasse umzuformen wenn so viel abgrenzbare Dinge (derzeit lokale Proceduren) gemacht werden?

**r2c2**

Ich finde die "Nested Functions" - so heißen die Viecher IMHO - manchmal auch praktisch. Zugegeben nicht immer. Aber in C# und C++(Hab grad n Ferienjob, bei dem ich C++Builder progge) fehlen sie mir manchmal sogar. Und zwar genau dann, wenn man Funktionen in Teilfunktionen aufteilen will, sich das Ganze aber nicht bzw. nur schwer oder nur eingeschränkt sinnvoll in eine Klasse auslagern lässt[1]. In gewissem Sinne(Information- bzw. FunctionHiding) entspricht das sogar den Prinzipien der OOP.

N Beispiel, das jeder kennt, und wo NestedFunctions IMHO sinnvoll eingesetzt werden: QuickSort...

[1] zugegebn n schmaler Bereich...

mfg

Christian

**Meflin**

Zitat von RavenIV:

Ich möchte Dir nicht zu nahe treten, aber da würde ich das Design der Software nochmal überdenken...

dann nenne ich dir mal ein anderes Beispiel: ich hatte mal eine thread-Funktion, in der eine bestimmte Operation ausgeführt werden sollte. Diese Funktion war so etwa 15,20 Zeilen lang (wie süß

) Der Rest der Threadfunktion, das ganmze Verwaltungs-drumherum war um einiges länger.

Und was spricht jetzt bitteschön dagegen diese 15 Zeilen Code in eine Lokale function auszulagern und in der Threadfunktion aufzurufen? Wie unübersichtlich! Welch schlechtes Softwaredesign!

So findet man jedenfalls die eigenltiche *Funktion* des Threads wesentlich schneller...

**TBx**

also mal ganz ehrlich: alienous hatte gefragt, worin die Bedeutung der Functionen/Prozeduren innerhalb anderer Funktionen/Prozeduren liegt. Das ist mit der Erklärung des Scopes beantwortet worden.
Jetzt entsteht hier wieder mal eine Debatte darüber, ob die Verwendung eines Faetures von Delphi guter oder schlechter Programmierstil ist.
Muß das denn sein? Dann können wir ja auch gleich in

diesem Thread weitermachen.

Entschuldigt bitte, wenn das etwas säuerlich klingt, aber ich finde, das Diskussionen sachlich sein sollten. Anderen ein schlechtes Design vorzuwerfen, ohne dessen Programmierung zu kennen, ist sicherlich keine konstruktive Kritik.

Ich für meinen Teil kann sagen, daß sowohl nested Functions als auch Auslagerung in entsprechende Klassen Ihre Berechtigung haben. Welches Mittel man wann wählt, ist dem Programmierer nunmal selbst überlassen.

Gruß

onlinekater

**Der_Unwissende**

Zitat von onlinekater:

Jetzt entsteht hier wieder mal eine Debatte darüber, ob die Verwendung eines Faetures von Delphi guter oder schlechter Programmierstil ist.
...
Entschuldigt bitte, wenn das etwas säuerlich klingt, aber ich finde, das Diskussionen sachlich sein sollten. Anderen ein schlechtes Design vorzuwerfen, ohne dessen Programmierung zu kennen, ist sicherlich keine konstruktive Kritik.

Ja, sachlich diskutieren ist ja schön und gut! Das würde damit anfangen, dass ich jetzt nicht die Stelle finde wo der Programmierstil von jmd. kritisiert wurde. Was die Kritik am Softwaredesign anging, so wird hier sehr kontextfrei das Zitat

Zitat von RavenIV:

Ich möchte Dir nicht zu nahe treten, aber da würde ich das Design der Software nochmal überdenken...

[/quote]
verwendet. Allerdings wurde direkt vorher von einer Funktion mit 20 benötigten Parametern und 500 Zeilen (inkl. allen Unterfunktionen) gesprochen. Ich denke da ist es durchaus angebracht Kritik an der Funktion zu üben, 500 Zeilen sind doch wohl mit sehr hoher Wahrscheinlichkeit teilbar (und für mich komplett unleserlich).

Natürlich verbietet einem keiner Funktionen in andere einzubetten. Natürlich ist das kein schlechter Programmierstil, aber definitiv kein OO Design. Imho wurde mehr nicht gesagt. Es verlangt keiner dass Delphi Programmierer OO arbeiten! Aber es bietet Möglichkeiten und ein Hinweis auf diese denke ich sind total ok.

Ich seh ehrlich gesagt noch nicht den sachlichen Vorteil darin, dass ich eine Funktion innerhalb einer Funktion verwende. Als Nachteile sehe ich weiterhin, dass die Lesbarkeit reduziert wird. Man sieht meiner Meinung nach nicht sofort, wo was herkommt. Insbesondere das Variablen aus der umgebenden Funktion verwendet werden können senkt schon alleine die Lesbarkeit. Die dürften sich schwer qualifizieren lassen und sind weder als Parameter übergeben, noch in der Funktion lokal! Habe ich also 3 solcher Funktionen in einer Funktion kann ich erstmal suchen wo welche Funktion aufhört und von der untersten aus suchen, wo die Variablen deklariert sind.
Insbesondere Anfänger haben (meiner Erfahrung nach) sehr viele Probleme mit dem lesen solcher Funktionen. Ohne Frage, man bekommt jedes Programm unleserlich, aber es gibt Dinge die etwas erleichtern oder erschweren. Ich sehe hier eine Möglichkeit die Lesbarkeit zu verringern, aber noch keinen Vorteil. Warum sollte eine private Methode eine andere private Methode nicht kennen? Da ich von Methoden spreche gehören sie zu einem Objekt, da sie privat sind, können beide nicht von aussen gesehen werden. Ich habe hier also eine (imho gute) Alternative. Methoden sehen immer gleich aus und ich würde sofort sehen ob es sich um lokale Variablen oder Instanzvariablen handelt (mit Qualifizierung durch self.).

**negaH**

Zitat:

Also mir kommt auch immer die Galle hoch, wenn ich eine Procedure/Function in einer Procedure/Function sehe (sogenannte lokale Proceduren/Funktionen).
Mit OO hat dies nix mehr zu tun, da kann ich ja grad alles in eine Main-Function reinschreiben. Uaaargs!

Ich löse sowas immer mit einer Klassenmethode, evtl wird diese überladen oder mit Default-Parametern versehen...

Tja, dann scheinst du die Grundlagen der prozeduralen Programmierung, genauer gesagt der Modularisierung, Abstraktion und BlackBox Prinzip, nicht vestanden.

Nested Functions -> verschachtelte lokale Funktionen, sind ein sehr starkes Instrument in der Programmierung um ein komplexes und nicht weiter reduzierbares Problem (reduzierbar zb. per OOP) einfacher und modularisierter umzusetzen.

Defakto sind nested Functions die konsequente Umsetzung des Prinzips der Abstraktion, das zb. auch in Delphi über Program -> Units -> Interface -> Implementation -> Function -> nested Function.

Ich persönlich erachte also nested Functionen als sehr guten Stil. Das hat mehrere Gründe:

1.) abstraktion eines Problems durch Zerlegung in immer kleinere und übersichtlichere Teilprobleme
2.) besser Lesbar, da man wenn man eine Funktion als BlackBox verstanden hat, deren Implementierung quasi wieder vergessen kann, es interessiert dann nur noch der Name, In/Out Parameter dieser Funktionen
3.) da nested Funktionen nun mit sehr wenigen Sourcezeilen, Parameter und lokalen Variablen auskommen (entgegen eine rießigen komplexen single Funktion) kann der Delphi Compiler den erzeugten Code optimieren.
4.) es gibt keine andere Möglichkeit als eine nested Funktion wenn man ein Problem als Black Box so stark abstrahieren möchte das diese Details nirgends von aussen sichtbar sind. Dh. wenn man innerhalb einer Funktion einen Code mehrmals benötigt und diesen in eine Funktion auslagert, dann ist die stärkste Un-sichtbarkeits-stufe nur eine nested Funktion. Eine nicht-nested Funktion wäre also sichtbar für andere Funktionen, das ist aber unerwünscht.

Mit nested Funktionen kann man also ein Problem nicht nur sauberer lösen sondern der erzeugte Maschinencode wird auf Grund der besseren optimierung durch den Compiler auch schneller sein.

Dazu muß man aber auch wissen wie der Compiler überhaupt einen Code optimiert. In diesem Falle interessiert uns nur die Frage wie der Compiler mit den vorhandenen Prozessorregistern umgeht. Und da ist es so das diese Register der CPU in ihrer Anzahl begrenzt sind und der Compiler immer versucht möglichst viele lokale Variblen in Registern zu halten. Je komplexer eine Funktion ist desto mehr lokale Variablen wird sie benötigen und um so mehr steht der Optimierer unter Registerdruck, dh. er hat normalerweise nicht genügend CPU Register zur Verfügung um alle lokalen Variablen der Funktion darin zu optimieren.

Mit nested Funktionen zerlegt man nun diese komplexe Funktion in so viele Teil-Funktionen (nested) das jede dieser Funktionen nun mit wesentlich weniger lokalen Variablen auskommen. Nun kann der Compiler diese Teil-Funktionen weit besser optimieren.

Der Compiler betrachtet nämlich einen Code innerhalb einer Funktion immer als Optimierungs-Einheit, als Ganzes das er optimieren soll. Der Delphi Compiler kann NICHT Code über Funktionsgrenzen hinweg optimieren und um so wichtiger wird es das man die eigenen Funktionen so weit vereinfacht das er möglichst alle lokalen Variablen in Registern halten kann.

Gruß Hagen

**xaromz**

Hallo,

Zitat von Der_Unwissende:

Ja, sachlich diskutieren ist ja schön und gut! Das würde damit anfangen, dass ich jetzt nicht die Stelle finde wo der Programmierstil von jmd. kritisiert wurde. Was die Kritik am Softwaredesign anging, so wird hier sehr kontextfrei das Zitat

Zitat von RavenIV:

Ich möchte Dir nicht zu nahe treten, aber da würde ich das Design der Software nochmal überdenken...

verwendet. Allerdings wurde direkt vorher von einer Funktion mit 20 benötigten Parametern und 500 Zeilen (inkl. allen Unterfunktionen) gesprochen. Ich denke da ist es durchaus angebracht Kritik an der Funktion zu üben, 500 Zeilen sind doch wohl mit sehr hoher Wahrscheinlichkeit teilbar (und für mich komplett unleserlich).

Zu den 500 Zeilen: Die Zahl bezog sich eben auf die Prozedur mit sämtlichen Unterfunktionen. Ich habe also die Prozedur schon aufgeteilt.

Zitat von Der_Unwissende:

Ich seh ehrlich gesagt noch nicht den sachlichen Vorteil darin, dass ich eine Funktion innerhalb einer Funktion verwende. Als Nachteile sehe ich weiterhin, dass die Lesbarkeit reduziert wird. Man sieht meiner Meinung nach nicht sofort, wo was herkommt.

So ein großer Unterschied ist es jetzt nicht, ob erst ein Prozedurkopf kommt und dann einige Funktionen, oder erst die ganzen Funktionen und dann die Hauptprozedur. Das ist alles eine Frage der Formatierung.

Zitat von Der_Unwissende:

Insbesondere das Variablen aus der umgebenden Funktion verwendet werden können senkt schon alleine die Lesbarkeit. Die dürften sich schwer qualifizieren lassen und sind weder als Parameter übergeben, noch in der Funktion lokal! Habe ich also 3 solcher Funktionen in einer Funktion kann ich erstmal suchen wo welche Funktion aufhört und von der untersten aus suchen, wo die Variablen deklariert sind.

Wenn ich also aus der Prozedur eine Klasse baue, in der die Unterfunktionen private Methode sind, dann muss ich sämtliche Variablen, die vorher lokal in der Funktion deklariert waren, jetzt als Member in die Klasse aufnehmen. Außer einer anderen Quellcode-Formatierung habe ich damit eigentlich nichts gewonnen. Die Trennung der Variablen nach ihrer Verwendung lässt sich nämlich auch mit Nested Procedures bewerkstelligen.

Gruß
xaromz