Frage zu Refactoring statischer Methoden

[WeirdAl]

Hallo zusammen,
ich habe hier Legacy Code, bei dem der gesamte Business Layer aus Klassen mit statischen Methoden besteht. Der ganze Kram ist ungetestet und ich soll einzelne Methoden anfassen bzw. erweitern.
Da ich das Zeug jedoch testbar machen will, wollte ich die Methoden die ich anfasse unter Test stellen. Meine Frage ist jetzt, wie gehe ich da am Besten vor? Erstelle ich eine neue BusinessLayerklasse und verschiebe die anzupassende, statische Methode dahin und mache sie zu einer Instanzmethode?

Problem Nr. 2:
Innerhalb dieser Methode wird u.A. dann noch zu anderen statischen Methoden delegiert die noch Teildaten sammeln. Soll ich diese Delegation auslagern und die Teildaten von Außen in die Methode "injecten"?

Bislang war es so, das man mit Powermockito die statischen Methoden mocken musste. Davon wollte ich eigentlich weg.

Gibt es dazu irgendwelche Best Practices?

Cu
Alex

 

[bygones]

ist der Code in irgendeiner Form API die ausserhalb deines/eures Einflusses besteht ? Je nach dem wie stark du kompatibel bleiben musst macht es das refactoring immer etwas schwerer bzw aufwaendiger.

Du hast schonmal gut erkannt, dass Powermockito weg sollte, und dass statische Methoden (meist) fuer testbaren code schaedlich sind. Daher als generelle Methodik wuerde ich vorschlagen von innen nach aussen, test-getrieben die statischen Methoden umzuwandeln.
Bei statischen Methoden ist es oft, dass die Methoden eigentlich Teil einer Klasse einer der Paramter sein sollte. Math.abs(-3) waere dann zb eine Methode der "int" Klasse (sorry besseres bsp ist mir nicht eingefallen um das zu zeigen was ich mein).

Fuer jegliches Refactoring lege ich dir Home of the Mikado Method ans Herz, damit kann man wunderbar in kleinen Schritten code refactoren ohne in dem Wust von Aenderungen unterzugehen.

Der Ansatz von Instanzmethoden und Injection sind meiner Ansicht nach schon der richtige Weg

 

[faetzminator]

Ich würde mir neue, objektorientierte Hüllen bauen und allen alten Kram aufrufen. Dann kannst du Unit Tests schreiben und schrittweise alles refactoren.
Es gibt ab und zu tatsächlich die Berechtigung für statische Methoden (siehe z.B. [c]java.lang.Math[/c]), insofern würde ich nicht alles non-static schreiben, nur dass es so ist. Wenn es sinnvoll ist, wirst du das warscheinlich selbst bemerken. Ich verwende für statische Methoden bei der Arbeit auch Powermockito.

 

[WeirdAl]

Der Code hat keinen API Charakter. D.h. wenn ich refactore werde ich alle notwendigen Stellen direkt anpassen bzw. durch Eclipse anpassen lassen (soweit das automatisiert geht).

Ich werde mir den Link gleich mal ansehen.

 

[bygones]

Es gibt ab und zu tatsächlich die Berechtigung für statische Methoden (siehe z.B. [c]java.lang.Math[/c]), insofern würde ich nicht alles non-static schreiben, nur dass es so ist.

zur Anmerkung (auch wenn ich ein nicht-statisch-Fan bin), static Methods am Ende des Callgraphens sind ok (z.b. Math), da diese keine weitere logik oder somit weitere Aufrufe ausfuehren auf anderen Objekten oder anderen Systemen.

Alles andere ist schwer zu ueberlegen und behindert sinnvolles testen. Powermockito verschleiert hier das missglueckte Design eher imho