Vorteile:

• jede Klasse ist für sich klein und überschaubar
• die Zuständigkeit einer Klasse/Methode lässt sich gut scharf definieren
• die Komplexität von UnitTests wird verringert
• Bugs lassen sich leichter lokalisieren
• durch gute Namensgebung lässt sich die Funktionsweise der kurzen Codeblöcke gut dokumentieren, so dass der Bedarf für sonstige Dokumentation geringer wird
• das System ist flexibler im Verhalten, da es sich auf Klassen-Ebene (z.B. StrategieMuster?) bzw. Methoden-Ebene (durch Polymorphie, z.B. TemplateMethode?) variieren lässt, ohne RapeAndPasteProgrammierung? verwenden zu müssen
• ...

• tausende von kleinen Klassen sind in ihrer Gesamtheit wieder schwer überschaubar.
• ...

• die Größe von Klassen (oder Modulen) alleine kann kein Qualitätskriterium sein.
• andererseits führt die konsequente Vermeidung von dupliziertem Code fast zwangsweise zu einem VieleKleineTeile-Design
• es besteht die Gefahr, dass ein solches Design in ein reines Chaos mutiert; zum Glück gibt es Hilfsmittel, um den entgegen zu wirken:
• eine SystemMetapher, die die Entwicklung des Designs leitet und als Karte im 'Klassendschungel' dienen kann
• verschiedene Abstraktionsschichten, denen eine Klasse eindeutig zugeordnet werden kann
• in Java eine package-Hierarchie, um die Abstraktionsschichten deutlich zu machen
• ein gutes Namenssystem, so dass man nicht unbedingt die Implementierung aller kollaborierenden Klassen kennen muss, um die Arbeitsweise einer Klasse/Methode verstehen zu können
• EntwurfsMuster, die ein allgemeines Vokabular für häufig auftauchende Lösungen zur Verfügung stellen
• ein guter Klassenbrowser, der das Navigieren durch die Klassen vereinfacht
• ein guter RefactoringBrowser, der den Kampf gegen das Chaos vereinfacht
• ...

Was die Überschaubarkeit angeht: Mir fällt es (mit Hilfe von modernen Entwicklungstools) wesentlich leichter, durch eine Reihe von vielen kleinen Einheiten zu navigieren und mir so Stück für Stück ein Bild von der Arbeitsweise eines Systems zu machen, als ein monolithisches System zu analysieren, wo ich zwar quasi den gesamten Code auf einen Blick zur Verfügung habe, mir aber praktisch keine Hilfestellung in Form von verschiedenen Abstraktionen zur Verfügung gestellt wird. -- IljaPreuß

Im Gegensatz zur SpaghettiProgrammierung? wird diese Vorgehensweise auch gelegentlich als TortelliniProgrammierung? bezeichnet.

VieleKleineTeile entstehen insbesondere dann, wenn man Delegation statt Vererbung einsetzt und Objekte aus vielen kleinen Teilobjekten aggregiert. Dies ist eine natürliche Folge der Verwendung von Entwurfsmustern, die sehr oft Flexibilität durch Auslagern von Funktionalität erzeugen.

Wichtig ist es, diese größere Flexibilität auch nutzen zu können, um so die größere Komplexität abzufangen. Unnötige Komplexität führt zu Problemen. Nötige Komplexität ist in vielen kleinen Teilen oft am besten gebändigt.

Als Beipiel für eine nötige Komplexität, die wohl besser mit Hilfe eines VieleKleineTeile-Designs gebändigt worden wäre, sei an dieser Stelle noch einmal die Java-Klasse GridBagLayout? erwähnt. Wenn man mit diesem Monster arbeiten muss, fühlt man sich schnell als Löwenbändiger...

Durch VieleKleineTeile steigt die Wiederverwendungsrate. Deshalb glaube ich nicht daß die Anzahl der Klassen in einem Programm extrem steigt, wenn ich statt grosser Klassen VieleKleineTeile verwende. Bei komplexeren Programmen habe ich schon oft Klassen gesehen, die z.B.: Arbeitsplan1, Arbeitsplan2, Dummyarbeitsplan heissen. Da die grossen Klassen oft nur in einem speziellen Kontext ablaufen, haben 2 Programmierer (einer hiess Copy, der andere Paste) einfach kopiert und die Kopien der grossen Klassen dem jeweiligen Kontext angepasst.

Da kleine Klassen i.a. eine klare Aufgabe haben, ist es auch leichter diese eindeutig einem geeigneten Package zuzuordnen und werden daher auch schneller gefunden.

In einem Design Kurs habe ich zum Einstieg den Teilnehmern eine Klasse Person mit den Instanzvariablen name, alter, vorwahl, nachwahl gegeben und gefragt ob es sich lohnt daraus 2 Klassen Person und Telefon zu generieren. Mein Lösungsvorschlag: Wenn ich in einer Maske nur die Vor- und Nachwahl anzeige lohnt es sich nicht eine eigene Klasse Telephon zu generieren. Ich hätte dann eine Klasse die nur die Instanzvariablen setzt und wieder ausliest, aber ansonsten faul ist. Sobald ich eine Methode habe die sich nur auf Vorwahl und Nachwahl bezieht (z.B automatische Anwahl), und die anderen Instanzvariable der Person nicht benötigt, lohnt es sich eine eigene Klasse Telephon zu generieren. -- KlausMeucht

Siehe WardsWiki:LotsOfLittleMethods SmalltalkBestPracticePatterns