JM 4.06: Funktionale Programmierung

[Ch. Neumann]

FP implementiert den filter-Algorithmus nur ein einziges Mal!

In einer großen Softwareanwendung kommt das Filtern einer Liste o.ä. vielleicht 100, 500 oder 1000-mal vor. Dann kannst du 1000-mal den Algorithmus wieder implementieren, also deine for-Schleife immer wieder neu programmieren. Bei durchschnittlicher Länge von 10 Zeilen sind das also ca. 10000 (zehntausend) Programmzeilen.

Ich dagegen muss gar nicht überlegen, denn die einzige Zeile lautet immer noch:

FP.filter(new IsAvailable<RentalCar>, cars);

Auf das komplette Softwareprojekt sind das dann bei mir 1000 (tausend) Zeilen anstatt 10000 (zehntausend) Zeilen.

Außerdem kann ich keine Fehler machen, weil es filter nur ein einziges Mal gibt und der Algorithmus fehlerfrei ist. Bei dir gibt es 1000 potentielle Fehlerquellen, also deine for-Schleifen. Und Arbeitsaufwand spare ich jede Menge, genauer: Ich spare mir 1000 for-Schleifen.

Wenn man etwas abstrakt denken kann, dann hat das mit "over engeneering" nicht das Geringste zu tun.

Vielleicht fällt irgendwann der Groschen

[Foo Bar]

das ist lächerlich - wenn der eigentliche prozess mehr als 1 mal vorkommt stecke ich ihn eben in eine funktion

<pre>
for(Car car: cars){
if(car.isAvailable()){
tudiesunddasmitdem(car);
}
}
</pre>
Noch dazu muss ich dann nicht für jeden tudiesunddas einen neuen Filter schreiben, sondern kann die Funktion vielleicht auch anderweitig Nutzen

Warum sollte in einem einzigen Programm 1000 mal genau der gleiche "Prozess" aufgerufen werden, der mit der Zeile
<pre>
FP.filter(new IsAvailable<RentalCar>, cars);
</pre>
abgekürzt wird? Da schreib ich doch gleich eine Methode
<pre>
filterAvailableCars(car);
</pre>
dann wird das noch kürzer?

Bin einfach zu blöd für diese genialen Argumente, die Wahrheit ist doch, dass der Filtermechanismus lediglich
<pre>
for(Item x : listeVonXen){...}
</pre>
auf andere Art und Weise darstellt. Wo ist da der Vorteil? Zumal sowas in der Praxis nicht so oft vorkommt. Meistens hat man das ganze ja vielleicht nur 2 oder 3 mal, und dafür soll ich dann den ganzen FP Apparat einziehen

[Ch. Neumann]

Weißt du eigentlich was du tust?

FP.filter() funktioniert für alles was man filtern kann (Autos, Kunden, Bestellungen, Maßnahmen, …).

Ich brauche nur eine einzige Implementierung von filter und die funktioniert für das ganze Softwareprojekt.

Bei dir hingegen sind aber ganz schön viele Hilfsmethoden nötig:

filterAvailableCars();
filterCustomerById();
filterCustomerByOrders();
filterActions();
filterActionsByDeadline();
… // und noch viele Methoden mehr: 100? 200? 300?

Unwissenheit schützt vor Strafe nicht – deswegen der Künstlername „Foo Bar“

[Foo Bar]

das ist doch scheisse, hab ich gerade schon gesagt

ich muss bei diesem Beispiel immer einen EXTRA Filter schreiben -

class AvailableCars implements Function&lt;Customer,String&lt;
class CustomerById implements Function&lt;Customer,String&lt;
class CustomerByOrders implements Function&lt;Customer,String&lt;
class Actions implements Function&lt;Customer,String&lt;
class ActionsByDeadline implements Function&lt;Customer,String&lt;

(hab jetzt mal die Generics nicht angepasst)

ob ich jetzt diese klassen ausprogrammiere, oder die Hilfsmethoden, was ist der Vorteil?

in FP eine immer eigene nette kleine Klasse, die meinen Namensraum weiter zumüllt, mit einer möglicherweise komplizierten Zustandsfunktion (man denke an an die Summenbildung eine Liste von Integers)

und dann?

was ist der Vorteil gegenüber einer ebenfalls selbst geschriebenen static Method

<pre>
public static foobar machDenFilterMitMir(List<Car) cars){
for(Car car : cars){
... ich machs hier
}
}
</pre>
sag ich doch schon die ganze Zeit, der FP Filter-Trick abstrahiert im wesentlichen das Konstrukt
<pre>
for(Item x : liste){....}
</pre>
hinweg, und ob das jetzt so unglaublich fehleranfällig ist? Bin ich wirklich so blöd dass ich bei einer einfachen for-Schleife andauernd Fehler mache??

so gut die Idee auch ist, so schön wie in Lisp/Scheme wirds doch eh nie..

[Ch. Neumann]

<b>Der Künstler dokumentiert seine Wahrnehmungsstörung!</b><br>
Der Horizont endet eben nicht bei filter und/oder einer for-Schleife: Was ist mit den anderen Algorithmen wie reduce, map, currying, slice, zip, some, every, ...?<br>
Je nahe liegender die Idee, desto länger scheint es manchmal zu dauern, bis der Groschen fällt!<br>
Hier noch ein Tipp an die beiden Künstler: Immer nur lernen ohne dabei nachzudenken, das führt zu Verwirrung. Immer nur nachdenken ohne dabei zu lernen, das führt zu Erschöpfung

[Foo Bar]

Immer recht haben zu wollen und andere herunterzumachen führt bei gleichzeitiger Verwendung von &lt;T extends String&gt; zu Irritationen

[Ch. Neumann]

Wenn du die große Erleuchtung erreichen willst, schreite in ein Generics-Seminar wie ein junger Hirsch..

[Foo Bar]

muss jetzt wohl sein, jetzt haben Sie mir das so oft gesagt, wahrscheinlich habe ich tatsächlich ein Verständnisdefizit

im übrigen BIN ich ein junger Hirsch und lerne gern dazu

ich kanns kaum erwarten dass ich mich hier selber verbessern muss; möglicherweise melde ich mich dann in ein paar Wochen wieder mit folgendem Statement
<b>
&lt;T extends String&gt; ist doch kein sinnloser Bockmist wie ich hier immer behauptet habe, sondern eine sinnvolle und elegante Anwendung von Generics
<br /><br />
Ch. Neumann hatte recht, ich habe mich geirrt!
</b>
das wär toll (dann wüsste ich, dass ich wirklich was dazugelernt habe), im Moment kann ich mir leider nicht vorstellen wie das gehen sol

[bogart]

so schlecht können diese Ansätze garnicht sein, schließlich werden Generics und funktionale Programmierung auch in den neuen Versionen 2 und 3 von C# nach und nach umgesetzt.

bo (Steffen Hübner

[Ch. Neumann]

Der Meister sprach zum Künstler: "Ich habe einmal einen Tag lang nicht gegessen und eine Nacht lang nicht geschlafen, um nachzudenken. Das hat nicht geholfen - besser ist es, stattdessen zu lernen."
<br>
Zur Erinnerung: Wir sind hier nicht in Lisp oder Scheme (wie oben angedeutet), sondern in Java. Deswegen auch „Java Magazin“. Des Weiteren geht es im Artikel nicht primär um Java Generics, sondern um das Thema „Funktionale Programmierung mit Java 5“. Die Generics Syntax kann man sowieso nicht ändern – und die Diskussion gehört auch nicht zum Artikel. Darüber muss ich nicht wochenlang nachdenken

[bogart]

stimmt! ein guter schlusssatz!

b

[muffin]

Sie sollten die Kritik nicht persönlich nehmen, bzw. nicht ausfallend werden. Ein wesentlicher Bestandteil zum Verstehen des generischen Algorithmus sind nunmal die Generics. Tip für die Zukunft: Einfach als Einstiegsvoraussetzung nennen oder erläutern.

Ich finde es gut, dass Sie diesen Denkansatz vorgestellt haben, die Vorteile sind für mich erkennbar. Dennoch habe ich noch eine Frage:

Haben Sie vielleicht noch mehr Beispiele als im Artikel parat bzw. mehr Einsatzbereiche in der Praxis parat. So schön der Ansatz auch ist, es fällt mir schwer momentan einen weiteren konkreten Anwendungsfall zu finden.

Gruß

Dieter Gwen