Premature Abstraction

Tags:

Wir hören viel über Premature Optimization und wie böse es ist, da wir versuchen unseren Code zu optimieren, bevor wir überhaupt wissen können, ob er optimiert werden muss. Deshalb sollten wir es nicht tun, da es in den meisten Fällen nicht nötig sein wird.

Heute sprechen wir über etwas Ähnliches: Premature Abstraction, also voreilige Abstraktion.

Abstraktion ist doch toll?!

Je länger wir schon programmieren, desto mehr Erfahrung haben wir. Sollten wir jedenfalls, sonst läuft etwas schief. :) Erfahrung bringt mit sich, dass wir ein Problem besser analysieren und in Code lösen können. Zu Beginn unserer Programmierkarriere schrieben wir Spaghetticode, heute teilen wir den Code in Module, Klassen, Bereiche, Aufgaben, Funktion, etc. auf. Wir schreiben mehr Code als bei der anfänglichen Spaghettilösung. Dieser Mehraufwand ist fast immer Abstraktion. Doch wieso tun wir das eigentlich?

Nun, einerseits wird unser Code dadurch wiederverwendbar. Er lässt sich einfacher verändern und warten, denn die Abhängigkeiten sind klarer und wir müssen nicht bangen, dass bei der kleinsten Veränderung an Stelle A plötzlich Stelle B abraucht. Abstraktion kapselt also Lösungen; und ist deshalb auch einfacher zu erweitern.

Wo liegt nun also das Problem mit Abstraktion?

Das Problem liegt nicht an der Abstraktion, sondern am Zeitpunkt wo wir sie anwenden. Wir neigen dazu Probleme überkompliziert zu lösen. Das aus dem Grund, weil wir schon viel weiter denken als wir müssten.

Unsere Applikation muss Uploads speichern können. Falls wir gross rauskommen, werden wir die Daten vermutlich bei Rackspace oder Amazon speichern. Ich sollte das also berücksichtigen.

Guter Gedankengang! Und schon schreiben wir nebst der UploadedFile-Klasse auch noch eine Storage-Klasse, die das Strategy Pattern implementiert und die Klasse FileSystemStorageStrategy nach sich zieht. Falls wir jetzt also später mal die Uploads bei Amazon speichern wollen, reichen wir einfach eine AmazonS3StorageStrategy-Klasse nach und ändern ein paar wenige Code-Stellen.

Hach, was für eine schöne Lösung. Schade nur, dass jetzt der Tag schon rum ist und wir unsere anderen Tickets nicht abgearbeitet haben. Und was ist, wenn wir mit unserer schicken Applikation jetzt gar nie abheben und die Uploads nie bei Amazon gespeichert werden müssen? Richtig, wir haben Zeit verschwendet. Abstraktion wird oft schlicht nicht gebraucht. Solange ein Problem nur einmal gelöst werden muss, müssen wir es nicht unnötig abstrahieren. Das ist Zeitverschwendung.

Falls unsere Dateien einestages tatsächlich bei Amazon gespeichert werden müssen, können wir oben genannte Abstraktion immer noch einbauen. Wir verlieren durch die Verzögerung der Implementation keine (oder nur minimale) Zeit. Der Aufwand ist ja der gleiche. Also mal davon ausgegangen, dass wir die "Datei auf Dateisystem speichern"-Funktionalität gekapselt haben. Denn die wird ja vermutlich bereits an mehreren Stellen in unserer Applikation gebraucht.

Abstraktionen haben noch ein weiteres Problem: Sie sind schwierig und wir brauchen - wie anfangs geschrieben - genügend Erfahrung um sie korrekt umzusetzen. Manchmal sind die Anforderungen aber so unklar, dass wir gar noch nicht wissen können wie sich etwas entwicklen wird. Wir können uns deshalb durch voreilige Abstraktion sogar den Code verbauen, so dass es später komplizierter wird, ihn zu erweitern. In dem wir Abstaktion später einführen, haben wir einen Wissensvorsprung. Die Lösung wird besser.

Fazit

Abstraktion ist gut und wichtig! Wir müssen uns aber zügeln, damit wir keinen geilen Code-Pr0n schreiben, sondern die einfache Lösung umsetzen. Wir können oft schlecht abschätzen wie sich eine Applikation entwickeln wird. Deshalb sollten wir aufpassen, dass wir nicht überkonzipieren.

Ähnliche Artikel

Kommentare