// Codebeispiel 1 // Kammstruktur I public static String eineMethode(String string){ tuDies(string); tuDas(string); tuJenes(string); return string; }

Genauso sieht es auch hier aus, da hier einfach mit dem Rückgabewert gearbeitet wird:

// Codebeispiel 2 // Kammstruktur II public static String eineMethode(String string){ return tuJenes(tuDas(tuDies(string))); }

// Codebeispiel 3 // Treppenstruktur public static String eineMethode(String string){ // implementierte Funktionalität bzgl. string return tuJenes(string); } public static String tuJenes(String string){ // implementierte Funktionalität bzgl. string return tuDas(string); } public static String tuDas(String string){ // implementierte Funktionalität bzgl. string return tuDies(string); } public static String tuDies(String string){ // implementierte Funktionalität bzgl. string return string; }

Nun ist es aber so, daß dieses RefactoringBeispiel die Treppen- und die Kammstruktur miteinander vermischt und ich frage mich jetzt, nach welchen Kriterien vermischt wurde? Oder anders gefragt: wann sollte zu welcher Struktur hin refaktorisiert werden?

Zur Illustration betrachten wir Codebeispiel 1 und 3.

In 1 werden die Methoden in dieser Reihenfolge traversiert:

• eineMethode
• tuDies
• eineMethode
• tuDas
• eineMethode
• tuJenes
• eineMethode

Das Codebeispiel 3 ebenso dargestellt:

• eineMethode
• tuDies
• tuDas
• tuJenes
• tuDas
• tuDies
• eineMethode

Hier wird die Kontrolle vollständig an die Untermethoden abgegeben und die Obermethode eineMethode bekommt erst wieder das Gesamtergebnis zu sehen.

[Die Treppenstruktur] erhöht die Möglichkeit der Wiederverwendung von umfangreicher Funktionalität (da jeder Schritt viel Funktionalität kapselt). Auch die Wahrscheinlichkeit von Vererbung dieser Funktionalität ist hoch. Im Hinblick auf die Weiderverwendung von reinen Datenobjekten (welche keine Geschäftslogik implementieren) besitzt [die Kammstruktur] Vorteile, da diese ohne jegliche interne Konsistenzprüfung (die Konsistenzbedingungen wecheln von System zu System) leichter wiederzuverwenden sind. Betrachtet man den Aspekt der Wartbarkeit, ist ebenfalls [die Kammstruktur] von Vorteil, da die Änderungen an einer zentralen Stelle durchgeführt werden.

weitere Diskussion

Ich glaube nicht, dass man diese Frage pauschal beantworten kann - besser geeignet ist IMHO immer diejeniege Struktur, die besser ausdrückt, was eigentlich passiert. Im wesentlichen ist es IMO vorteilhaft, wenn der Inhalt einer Methode sich auf einem gemeinsamen Abstraktionslevel befindet und betrachtet werden kann, als würde er eine neue atomare Aktion formen. Meist korreliert das recht gut zu den beiden Eigenschaften "liest sich der Rumpf flüssig" und "finde ich einen guten Methodennamen", denke ich.

Ich grübel noch ein wenig...:-)

... und komme, was das Refactoring betrifft, auf keinen grünen Zweig. Allerdings ist mir bei der Spielerei mit dem Code noch eine Verbesserung aufgefallen in der Methode longestConsecutiveMatch. Da kann man noch eine zusätzliche Abfrage einfügen. Fällt nicht gerade mit dem "Mississippi"-Testwort ins Gewicht, aber bei z.B. "MississippiMississippi?" macht das schon ca. 12,5% mehr Geschwindigkeit aus. Hier der Code dazu:

private static String longestConsecutiveMatch(String[] strings) { String currentLongest = ""; for (int index = 0; index < strings.length - 1; index++) { final int currentLength = headingMatchLength(strings[index], strings[index + 1]); if (currentLength > currentLongest.length()) { currentLongest = strings[index].substring(0, currentLength); } if(currentLongest.length() > index + 2){ break; } } return currentLongest; }

Das hinzugefügte habe ich rot hinterlegt. -- bs

Ich denke, das lässt sich so abstrakt nicht entscheiden. Ich kann mich ehrlich gesagt auch nicht mehr recht an unsere vorherige Diskussion erinnern (war das in news:comp.object?) - hatten wir da ein konkreteres Beispiel?

Werden die Kombinationsmethoden ins Objekt gesteckt, dann blähen sie es unnotwendig auf (und nichts in der OO-Philosophie beschäftigt sich mit diesem Problem) und ausserdem geht das nur in der speziellen Situation, wenn man über die Kompetenz (Source, Rechte) für das Objekt verfügt. Werden die Kombinationsmethoden aber in irgendeine Utility-Klasse gesteckt, so verschlechtern sie die Wiederverwendbarkeit allgemein, vor allem aber über Projektgrenzen hinweg (was kein OO-Mensch gerne hört). -- HelmutLeitner

Mhh, ich habe das Gefühl, dass das eher technische Probleme sind, die von unterschiedlichen Sprachen mit unterschiedlichem Erfolg gelöst werden. So kann man z.B. in der SpracheSmalltalk Methoden verschiedenen Kategorien zuordnen und nur innerhalb bestimmter Applikationen definieren. In der SpracheRuby kann man meines Wissens nach sogar einzelne Objekte zur Laufzeit um neue Methoden ergänzen, was vermutlich nicht mehr Kompetenz erfordert als die Methode in eine Utility-Klasse zu packen. Ich sehe ehrlich gesagt auch nicht ganz, wie eine Utility-Klasse im Allgemeinen die Wiederverwendbarkeit verschlechtert... habe aber das Gefühl, dass wir uns da schonmal uneins waren... ;) -- ip

Ja, es stammt aus dem DesignPatternBuch der GangOfFour. --bs

def fuehreKammAus tueWasSimples1 tueWasSimples2 tueWasKompliziertes tueWasSimples3 end

(PseudoCode entlehnt aus SpracheRuby)

Ob und inwieweit ich eine Methode wiederverwenden kann, muss zwar ebenfalls berücksichtigt werden, Betrachtung der Komplexität ist aber ein erster Schritt weg von der prozeduralen Denke. In dem Moment, wo meine Klasse durch Methoden unterschiedlicher Komplexität unübersichtlich wird, kann ich anfangen über Auslagerung dieser Anteile in eigene Klassen nachzudenken. Ziel des Ganzen sollte nicht der höchstmögliche Grad an Wiederverwendung, sondern eine gute Lesbarkeit sein. Bequemlichkeit sollte dabei überhaupt keine Rolle spielen. Auf Methoden tueDiesUndDannDas ist vorzugsweise dann zu verzichten, wenn

• dies und das voneinander unabhängig sind und
• einem kein griffiger Name für die Methode einfällt (CodeSmell).