Eine Schande, dass ich das "Ahlblog" von Martin Ahlborg nicht schön früher erwähnt und verlinkt habe. Die kleinen Programmiertipps und seine Gebote für Programmierer sind schon lange eine Erwähnung wert gewesen.
Herausgepickt habe ich mir hier den Artikel "Klein aber Fein - Der Wert kleiner Klassen" vom 3. September. In diesem Artikel beschreibt der Autor die Daumenregel, dass Klassen nicht zu groß werden sollten.
Klassen können [...] zu groß werden, weil sie borgmäßig Aufgaben von anderen Klassen assimilieren. In vertikaler Richtung kann eine Klasse beispielsweise gleichermaßen Highlevel- und Lowlevel-Funktionen haben. Dieses Problem findet man oft bei Kommunikationsschnittstellen. Da gibt es dann eine Klasse, die sowohl die ganzen Lowlevel-Kommunikationsdetails kapselt als auch Funktionen, die eigentlich ins Datenmodell gehören. In horizontaler Richtung kann eine Klasse Funktionalität implementieren, die eigentlich auf mehrere Klassen aufgeteilt werden sollte. Man kann dies gut erkennen, wenn man einen Teil der Klasse entfernen kann, ohne den Rest kaputt zu machen.
Was bringen mir eigentlich kleine Klassen? Nun, hauptsächlich wird man flexibler. Programme lassen sich leichter erweitern, da sich Erweiterungen auf die Implementation neuer Klassen und hier und da ein paar kleinen Codeänderungen beschränken. Ebenso erhöht sich die Wiederverwendbarkeit des Codes. Dadurch kommen weniger Codewiederholungen vor, eine der Hauptursachen für so richtig fiese Bugs.
Kleine Klassen lassen sich auch besser testen. Große Klassen tendieren dazu, viel Funktionalität intern zu kapseln. Es gibt keine Möglichkeit diese Funktionen direkt zu testen. Nutzt diese Klasse jedoch andere Klassen, die jeweils einen Teilbereich der Funktionen implementieren, dann lässt sich dieses Konglomerat besser testen, weil ich damit quasi Testschnittstellen geschaffen habe. Ich kann jetzt interne Funktionen testen, ohne dass ich Raum und Zeit verbiegen muss.
Meiner Erfahrung nach, ist die Regel, dass eine Klasse nur reine Aufgabe haben sollte, die entscheidendere und passendere Daumenregel. Eine Folge dieser Regel sind dann meist kleinere Klassen. Deshalb störe ich mich auch etwas an dem Hinweis auf 400 Lines of Code (aber auch der Autor sieht es nur als ungefähren Wert). Dennoch ein gut geschriebener, lesenswerter Artikel wie (ich befürchte ich wiederhole mich) viele Artikel in dem Blog.
"Head First Design Pattern" nennt diese Regel "Eine Klasse sollte nur einen Grund haben sich zu ändern", aber im Endeffekt läuft es auf das Gleiche hinaus.
No comments:
Post a Comment