2013-02-08 11 views
6

Pracuję na dość dużym produkcie. Jest już w fazie rozwoju, ponieważ .Net 1.0 był wciąż w toku i dlatego ma dużo złej jakości kod i nie został napisany z myślą o testach jednostkowych. Teraz staramy się poprawić jakość i wdrożyć testy dla każdej funkcji i naprawić błąd. Jednym z największych problemów, jakie mamy teraz, jest uzależnienie od piekła i przedmiotów bogów. W szczególności jeden obiekt bożka jest zły: Session. Zasadniczo wszystko związane z bieżącą sesją programu znajduje się w tym obiekcie. Istnieje również kilka innych obiektów bogów.Dziedziczenie interfejsu do rozpadu bogów obiektów?

W każdym razie, uczyniłem ten obiekt bogów "mocowalnym" za pomocą Resharpera, aby wyodrębnić z nich interfejs. Jednak nadal sprawia to, że trudno jest przetestować, ponieważ większość czasu trzeba spojrzeć na kod, który piszesz, aby dowiedzieć się, co naprawdę wymaga wyłudzenia ze 100 różnych metod i właściwości.

Właśnie podział tej klasy jest obecnie wykluczony, ponieważ istnieją dosłownie setki, jeśli nie tysiące odniesień do tej klasy.

Ponieważ mam interfejs (i prawie cały kod został refaktoryzowany, aby korzystać z interfejsu), miałem ciekawy pomysł. Co się stanie, jeśli interfejs ISession zostanie odziedziczony z innych interfejsów.

Na przykład, jeśli mamy coś takiego:

interface IBar 
{ 
    string Baz{get;set;} 
} 

interface IFoo 
{ 
    string Biz{get;set;} 
} 

interface ISession: IFoo, IBar 
{ 
} 

W ten sposób istniejący kod za pomocą ISession nie muszą być aktualizowane, ani też faktyczna realizacja muszą być aktualizowane. Ale w nowym kodzie, który piszemy i refaktoryzujemy, możemy użyć bardziej ziarnistych interfejsów IFoo lub IBar, ale przekazać w ISIZ.

I ostatecznie, widzę to jako prawdopodobnie ułatwiając ostatecznie zerwać rzeczywistą ISession i Boga sesja interfejsu/przedmiot

teraz do ciebie. Czy to dobry sposób na testowanie tych bogów i ostatecznie ich rozbicie? Czy jest to udokumentowane podejście i/lub wzorzec projektowy? Czy kiedykolwiek zrobiłeś coś takiego?

+3

+1: To brzmi jak rozsądny sposób na przeprowadzenie refaktoryzacji krok po kroku. –

+0

Jeśli go nie sprawdziłeś, [Efektywnie działający ze starszym kodem] (http://amzn.com/B005OYHF0A) autorstwa Michaela Feathersa może okazać się wartościowy. Zawiera wiele strategii, które pomogą Ci przeprowadzić testowany projekt. Wiele z nich jest oczywistych, ale zobaczenie ich w druku, daje pewność, że można je przeforsować i zrobić to. –

+1

@AnthonyPegram to kolejna książka na mojej liście, aby uzyskać – Earlz

Odpowiedz

6

Z mojego punktu widzenia jest to dobre i właściwe podejście. Później można wstrzyknąć bardziej specyficzne instancje usługi, niż IFoo/IBar, a nie ISession, powiedziałbym, że jest to dobry krok pośredni przed dalszym refaktoryzacją, aby wyodrębnić klasy z klasy boga do wielu konkretnych usług.

Niektóre zalety widać:

Etap pierwszy: interfejsy ekstrakt

  • super (Boga) klasy typu są wydobywane przez interfejsy
  • kodowego przybiera mniej połączonych ponieważ opiera się na jednofunkcyjne odpowiedzialne interfejsy (usługi)
  • Macie grunt, aby posunąć się dalej i podzielić klasę bogów na wiele usług, bez masywnego refaktoryzacji, co już polega na interfejsach API

Drugi etap: podzielić klasę Boga w wielu drobnych usług z zachowaniem Single Responsibility principle pamiętać

trzecie stadium: Structurize istniejące testy jednostkowe tak testów zgrupowanych od rodzaju usług, a nie wszystkie razem wokół bóg klasy

Powiązane problemy