Читать книгу Prinzipien des Softwaredesigns - John Ousterhout - Страница 26

Leider wird der Wert tiefer Klassen heutzutage nicht allzu sehr anerkannt. Üblicherweise ist man in der Programmierung der Ansicht, dass Klassen klein und nicht tief sein sollten. Häufig wird Studierenden beigebracht, dass es beim Design von Klassen am wichtigsten sei, größere Klassen in kleinere aufzuteilen. Den gleichen Rat gibt es auch oft bei Methoden: »Jede Methode, die größer als N Zeilen ist, sollte in mehrere Methoden aufgeteilt werden.« (N kann auch einen Wert von nur 10 haben.) Dieser Ansatz führt zu vielen flachen Klassen und Methoden, die die Gesamtkomplexität des Systems vergrößern.

Das Extrem beim »Klassen sollten klein sein«-Ansatz ist ein Syndrom, das ich als Klassizitis bezeichne und das von der irrtümlichen Ansicht herrührt, dass »Klassen gut sind und mehr Klassen also besser sind«. In Systemen, die an Klassizitis leiden, werden Entwicklerinnen und Entwickler darin bestärkt, die Menge an Funktionalität in jeder neuen Klasse zu minimieren: Wollen Sie mehr Funktionalität haben, bringen Sie mehr Klassen ins Spiel. Klassizitis kann zu Klassen führen, die für sich betrachtet einfach sind, aber die Komplexität des Gesamtsystems vergrößern. Kleine Klassen tragen nicht viel Funktionalität bei, daher muss es viele von ihnen geben, die jeweils eine eigene Schnittstelle besitzen. Diese Schnittstellen summieren sich auf Systemebene zu einer unglaublichen Komplexität auf. Kleine Klassen führen zudem zu einem weitschweifigen Programmierstil, weil jede Klasse immer wieder neuen Code erfordert.