Refactoring. Ihre Methode, die Code-Komplexität großer Klassen mit großen Methoden zu reduzieren

8

Ich habe eine Legacy-Klasse, die ziemlich komplex zu verwalten ist:

%Vor%

Die Methoden sind riesig, unstrukturiert und repetitiv (Entwickler liebte Copy / Paste-Ansatz). Ich möchte jede Methode in 3-5 kleine Funktionen aufteilen, mit einer Pulic-Methode und mehreren Helfern.

Was würden Sie vorschlagen? Mehrere Ideen kommen mir in den Sinn:

  • Fügen Sie jeder Methode mehrere private Hilfsmethoden hinzu und verbinden Sie sie in #region (einfaches Refactoring)

  • Verwenden Sie das Befehlsmuster (eine Befehlsklasse pro OldClass-Methode in einer separaten Datei).

  • Erstellen Sie eine statische Helferklasse pro Methode mit einer öffentlichen Methode & amp; mehrere private Hilfsmethoden. OldClass-Methoden delegieren die Implementierung an die entsprechende statische Klasse (ähnlich den Befehlen).

  • ?

Vielen Dank im Voraus!

    
Andrew Florko 08.06.2010, 04:41
quelle

5 Antworten

3

SRP - Prinzip der einheitlichen Verantwortlichkeit und TROCKEN - Wiederhole dich nicht

    
this. __curious_geek 08.06.2010, 05:12
quelle
1

Ich würde anfangen, die Bits zu finden, die sich wiederholen und sie in Hilfsfunktionen extrahieren. Sobald Sie die Codebasis auf diese Weise eingeschränkt haben, können Sie andere Möglichkeiten zum Refactoring in Betracht ziehen, und der Code wird sich viel leichter umwickeln lassen.

    
VeeArr 08.06.2010 04:45
quelle
1

Siehe SD CloneDR für ein Tool, das Ihnen sagen kann, welche Code-Blöcke Ihre Methoden gemeinsam haben, einschließlich möglicher Parametrierungen.

    
Ira Baxter 08.06.2010 05:09
quelle
0

TROCKEN - Wiederhole dich nicht.

Das erste, was ich immer mache, ist, (alle) Wiederholungen zu entfernen. Auch eine einzelne Zeile ist Wiederholung.

Das wird den Code normalisieren und Ihnen auch einige Verbesserungen geben, wie zum Beispiel den Code zu generalisieren.

    
griegs 08.06.2010 04:45
quelle
0
  1. Beginnen Sie mit dem Zuordnen der aktuellen Funktionalität und erstellen Sie ein UML-Klassendiagramm. Auf diese Weise können Sie effektiv DRY erreichen.

  2. Ändern Sie das Design, um effektiv und DRY zu sein, während Sie immer noch die Benutzeroberfläche Ihres Systems so gut wie möglich beibehalten.

  3. Dann schreiben Sie Komponententests für das neue System, es wäre besser, sie für das alte System zu schreiben, aber da Sie wahrscheinlich Methodennamen und Argumente ändern werden, können die Komponententests wahrscheinlich nicht funktionieren beide Systeme.

  4. Fragen Sie Ihren Manager nach dem Komponententest, haben Sie die Funktionalität richtig verstanden? Implementieren Sie keine neuen Funktionen, dies führt zu Problemen mit bestehenden Systemen, die den Code verwenden, und wenn Sie das neue Design richtig nutzen, fügen Sie neue Funktionen hinzu

  5. Implementieren Sie das genehmigte System.

  6. Verwenden Sie Standardwerte als Argumente, um das Überladen zu reduzieren: SelectUser(int userId = 0) kann mit SelectUser();

  7. aufgerufen werden
MrFox 08.06.2010 08:37
quelle

Tags und Links