Ich arbeite an einem ziemlich großen Produkt. Es befindet sich in der Entwicklung, da .Net 1.0 noch in Arbeit war und daher eine Menge schlechten Qualitätscodes enthält und nicht mit Komponententests erstellt wurde. Jetzt versuchen wir, die Qualität zu verbessern und Tests für jede Funktion und Fehlerbehebung zu implementieren. Eines der größten Probleme, die wir jetzt haben, ist Abhängigkeitshölle und Gott-Objekte. Es gibt insbesondere ein Gottobjekt, das schlecht ist: Session. Im Grunde befindet sich in diesem Objekt alles, was mit der aktuellen Sitzung des Programms zusammenhängt. Es gibt auch ein paar andere Götterobjekte.Schnittstellenvererbung, um Götterobjekte zu zerlegen?
Wie auch immer, wir haben dieses Gott-Objekt "mockbar" gemacht, indem wir Resharper benutzen, um eine Schnittstelle daraus zu extrahieren. Dies macht es jedoch immer noch schwierig zu testen, da Sie die meiste Zeit auf den Code achten müssen, den Sie schreiben, um herauszufinden, was wirklich von den 100 verschiedenen Methoden und Eigenschaften verspottet werden muss.
Das Teilen dieser Klasse ist momentan nicht möglich, da es buchstäblich Hunderte, wenn nicht Tausende von Referenzen auf diese Klasse gibt.
Da ich eine Schnittstelle habe (und fast der gesamte Code wurde überarbeitet, um die Schnittstelle zu verwenden), hatte ich eine interessante Idee. Was passiert, wenn ich die ISession Schnittstelle von anderen Schnittstellen geerbt habe?
Zum Beispiel, wenn wir so etwas wie dieses hatte:
interface IBar
{
string Baz{get;set;}
}
interface IFoo
{
string Biz{get;set;}
}
interface ISession: IFoo, IBar
{
}
Auf diese Weise vorhandenen Code ISession mit nicht aktualisiert werden müssen, noch ist die tatsächliche Implementierung aktualisiert werden müssen. Aber in neuem Code, den wir schreiben und umgestalten, können wir die granulareren IFoo oder IBar Interfaces benutzen, aber eine ISession einreichen.
Und schließlich sehe ich dies als wahrscheinlich machen zu brechen es einfacher, schließlich das eigentliche ISession und Session god Interface/Objekt
Sie jetzt. Ist das eine gute Methode, um gegen diese Gottobjekte zu testen und sie schließlich zu zerstören? Ist dies ein dokumentierter Ansatz und/oder ein Entwurfsmuster? Hast du jemals so etwas gemacht?
+1: Das klingt nach einem vernünftigen Weg, um ein Schritt-für-Schritt-Refactoring durchzuführen. –
Wenn Sie es nicht ausgecheckt haben, kann sich [Effectively With Legacy Code] (http://amzn.com/B005OYHF0A) von Michael Feathers als wertvoll erweisen. Es enthält viele Strategien, mit denen Sie ein solches Projekt unter Beweis stellen können. Viele von ihnen sind offensichtlich, aber wenn Sie sie in gedruckter Form sehen, können Sie sich darauf verlassen, dass Sie sich durchsetzen können. –
@AnthonyPegram das ist eigentlich das nächste Buch auf meiner Liste zu bekommen – Earlz