Viele Kleine Teile
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (zum vorhergehenden Autor) (Änderung, Korrektur, Normalansicht)

Verändert: 52c52
Siehe WardsWiki:LotsOfLittleMethods WardsWiki:OversizingClasses SmalltalkBestPracticePatterns
Siehe WardsWiki:LotsOfLittleMethods SmalltalkBestPracticePatterns

Entfernt: 55d54


ObjektOrientierteProgrammierung führt häufig zu Programmen, die aus vielen kleinen Klassen mit jeweils wenigen kleinen Methoden bestehen.

Vorteile:

Nachteile: Fazit:
Diskussion

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

Wichtig ist es, trotz einer großen Anzahl an Klassen die Anzahl der essentiellen Klassen im Rahmen zu halten. Oft kann viel Funktionalität hinter einem kleinen Interface versteckt werden. Oft können viele verschiedene Funktionalitäten hinter einem einheitlichen Interface versteckt werden. -- OlafKummer

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


KategorieOop
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 28. Januar 2003 19:23 (diff))
Suchbegriff: gesucht wird
im Titel
im Text