Testy jednostkowe klasy dziedziczącej po klasie bazowej

Odpowiedz Nowy wątek
2019-04-29 10:56
0

Hej, takie pytanie mi się nasunęło. Mam jakąś ABSTRAKCYJNĄ klasę bazową Item. Po niej dziedziczą inne klasy: A, B, C, D, E itd.

I teraz chciałbym zrobić testy jednostkowe klasy A. Czy powinienem zawrzeć tutaj również testy dla klasy bazowej i to samo zrobić w reszcie klas, czy jakoś inaczej. Jak takie rzeczy testujecie u siebie?

Pozostało 580 znaków

2019-05-03 18:53
2
TomRiddle napisał(a):

@Juhas: @somekind

Na razie nie usłyszałem jeszcze żadnego argumentu który powiedziałby w czym dziedziczenie jest lepsze od kompozycji.

Ja nie argumentuję za tym, bo ja nie stawiam takiej tezy. Cały czas odnoszę się do Twoich pierwotnych słów, z których wynika, że dla Ciebie dziedziczenie automatycznie oznacza zły design. A to nie jest prawda, bo nie każde dziedziczenie jest złe. Tak samo jak nie każde użycie static czy throw new Exception jest złe. Co więcej, użycie kompozycji nie oznacza od razu, że design jest dobry. (Często właśnie przez nadmiar kompozycji nie jest.)

Prawdą jest, że nadużywając dziedziczenia można się wpędzić w niezłe kłopoty. Ale to truizm, bo tak jest ze wszystkim.

TomRiddle napisał(a):

Wstrzyknąć klasę której konkretna klasa jest ustalone w compile-time'ie? Niby jak?

Chodziło mi o to, że klasa bazowa może używać kodu z innej klasy, czyli kompozycji.

We wzorcu chodzi o to że jakiś algorytm (czy to w klasie abstrakcyjnej czy zwykłej) wymaga szczegółów implementacyjnych dostarczanych:

  • albo przez implementację metod abstrakcyjnych (jeśli jest to rozwiązane przez dziedziczenie)
  • albo poprzez wstrzyknięcie odpowiedniego interfejsu implementującego te metody (jeśli jest to rozwiązane przez kompozycję).

Nie wiem czego to opis, ale na pewno nie tego wzorca. W metodzie szablonowej chodzi o to, że jest jakiś algorytm, który składa się szeregu kroków, z których część jest wspólna, a część zmienna w zależności od rodzaju przetwarzanych danych. Kod odpowiedzialny za wspólną część jest umieszczony w klasie bazowej, a części specyficzne w klasach potomnych.

Zauważcie, że drugie rozwiązanie ma wszystkie słodkie cechy OOP: Interface segregation, Open/Close, Polimorfizm, z tej wstrzykniętej implementacji można zrobić decorator, kompozyt, adapter, mniam oop.

Metoda szablonowa ma wszystkie cechy OOP, a polimorfizm jest podstawą jej działania.

PS: To ma jeszcze dodatkową wadę, bo jeśli zrobisz sobie klasę dziedziczącą-bazową (w języku z jedno-dziedziczeniem), i potem będziesz chciał w niej skorzystać ze zwalonej libki która udostępnia tylko API poprzez dziedziczenie - cóż (znów), nie masz szczęścia :>

No i znowu mamy problem niemożności zatankowania roweru. Nie ma najmniejszego powodu, aby moja metoda szablonowa nagle zaczęła dziedziczyć z jakiegoś cudzego kodu, więc nie ma sensu snuć takich rozważań.

Kompozycja ma swoje zastosowania - zgadzam się, wymieniam je od kilku godzin.

Nie wiadomo tylko po co. Każdy tutaj wie, do czego służy kompozycja i jakie są jej zalety.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0