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