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-04-30 19:59
0

Diamond Problem tylko dowodzi tego, co mówię. Że jeśli musisz dziedziczyć z więcej niż jednej klasy, to prawdopodobnie robisz coś źle. PRAWDOPODOBNIE. Poza tym to dość specyficzny przykład.

@somekind i ja próbujemy Ci powiedzieć, że kompozycja i dziedziczenie to dwie różne rzeczy. I nie można powiedzieć, że kompozycja jest lepsza od dziedziczenia, czy na odwrót, bo to tak jakbyś mówił, że jabłko jest lepsze od psa.

Pozostało 580 znaków

2019-04-30 20:13
0
Juhas napisał(a):

@somekind i ja próbujemy Ci powiedzieć, że kompozycja i dziedziczenie to dwie różne rzeczy. I nie można powiedzieć, że kompozycja jest lepsza od dziedziczenia, czy na odwrót, bo to tak jakbyś mówił, że jabłko jest lepsze od psa.

Ja mówię o ich porównaniu pod względem reużycia istniejącego kodu. W moim mniemaniu oba te sposoby próbują robić to samo, ale dziedziczenie jest w tym dużo gorsze.


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP

Pozostało 580 znaków

2019-04-30 23:00
0

Nie, to są zupełnie dwa różne zastosowania.

Pozostało 580 znaków

2019-05-01 00:23
0
Juhas napisał(a):

Nie, to są zupełnie dwa różne zastosowania.

Wymień proszę


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP

Pozostało 580 znaków

2019-05-01 07:11
0
Juhas napisał(a):

Diamond Problem tylko dowodzi tego, co mówię. Że jeśli musisz dziedziczyć z więcej niż jednej klasy, to prawdopodobnie robisz coś źle. PRAWDOPODOBNIE.

Języki wspierające traity i mixiny śmią się nie zgodzić. Ludzie boją się tego diamentu jak ognia, a to problem jak każdy inny, można sobie strzelić w stopę, ale tak samo można zrobić przeładowaniem metod, a tego nic nie zabrania.

edytowany 1x, ostatnio: Afish, 2019-05-01 07:19

Pozostało 580 znaków

2019-05-01 12:20
0
Afish napisał(a):
Juhas napisał(a):

Diamond Problem tylko dowodzi tego, co mówię. Że jeśli musisz dziedziczyć z więcej niż jednej klasy, to prawdopodobnie robisz coś źle. PRAWDOPODOBNIE.

Języki wspierające traity i mixiny śmią się nie zgodzić. Ludzie boją się tego diamentu jak ognia, a to problem jak każdy inny, można sobie strzelić w stopę, ale tak samo można zrobić przeładowaniem metod, a tego nic nie zabrania.

Na pewno wiesz co to jest problem diamentu? Nie chodzi o to że nie wiadomo którą implementację wykorzystać, tylko jak dziedziczysz z dwóch klas, która dziedziczy z jednej, to ta jedna zostanie załadowana do pamięci dwa razy.


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP
To jest problem jednej konkretnej implementacji wielodziedziczenia, niekoniecznie najlepszej. :P - Krolik 2019-05-07 12:38

Pozostało 580 znaków

2019-05-01 12:43
1

Na pewno wiesz co to jest problem diamentu? Nie chodzi o to że nie wiadomo którą implementację wykorzystać, tylko jak dziedziczysz z dwóch klas, która dziedziczy z jednej, to ta jedna zostanie załadowana do pamięci dwa razy.

Tak się dzieje w C++, ale nie w n.p. Scali. W Scali jest trait linearization: https://www.trivento.io/trait-linearization/

Scala trochę zmienia sposób dziedziczenia, by uniknąć problemów z C++ i wpasować się w ograniczenia JVMa. Na poziomie bajtkodu Javowa klasa może dziedziczyć tylko i wyłącznie po jednej klasie bazowej i takie samo ograniczenie jest w samej Scali - możesz dziedziczyć tylko po jednej klasie. Jednak Scala udostępnia traity, które są (w dużym uproszczeniu) interfejsami z implementacjami metod i stanem. Domieszanie traita Y do klasy X działa w ten sposób, że kompilator do klasy X dorzuca stan taki sam jak w traicie Y oraz dorzuca metody, które forwardują do metod z traitu Y. Przy domieszaniu traitu nie ma więc dziedziczenia na poziomie bajtkodu.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2019-05-01 12:51

Pozostało 580 znaków

2019-05-01 13:59
0

Jedyny powód testowania klasy bazowej może być pisanie jakiejś biblioteki czy frameworka, gdzie użycie owego rozwiązania wymaga od użytkownika dziedziczenia po jakiejś klasie bazowej. Wtedy piszesz sobie np. FakeKalasaDzieckoSut albo Out, Cut (Class under test) i testujesz to z rodzicem, tylko że trudno będzie to nazwać testem jednostkowym.

Wybór metody szablonowej lub strategi powinieneś motywować bardziej tym, co jest uogólnieniem a tym, co jest związane z jakąś akcją lub agregacją, czyli klient ma bilet do kina -> aggregacja. Uogólnienie a agregacja — asocjacja to po prostu inny rodzaj związku.


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.

Pozostało 580 znaków

2019-05-01 15:48
0
TomRiddle napisał(a):

Na pewno wiesz co to jest problem diamentu? Nie chodzi o to że nie wiadomo którą implementację wykorzystać, tylko jak dziedziczysz z dwóch klas, która dziedziczy z jednej, to ta jedna zostanie załadowana do pamięci dwa razy.

Wikipedia śmie się nie zgodzić: https://en.wikipedia.org/wiki[...]heritance#The_diamond_problem
Problem diamentu rozbija się o semantykę wiązania, jak dziedziczę składową (pole, metodę, cokolwiek innego) z wielu ścieżek, to nie wiadomo, którą ścieżkę wybrać. Zerknij do artykułu na wiki i zobaczysz, że jest mnóstwo języków z tym problemem i jest mnóstwo rozwiązań.

To, co Ty opisujesz, to już szczegół implementacji C++, a nie immanentna cecha problemu diamentu. Co więcej, jeżeli myślisz, że w Javie nie ma problemu diamentu, bo nie ma dziedziczenia z wielu klas, to jesteś w błędzie, bo Java wprowadziła wielodziedziczenie implementacji przez domyślne metody w interfejsach.

Pozostało 580 znaków

2019-05-01 16:11
0

Na pewno wiesz co to jest problem diamentu? Nie chodzi o to że nie wiadomo którą implementację wykorzystać, tylko jak dziedziczysz z dwóch klas, która dziedziczy z jednej, to ta jedna zostanie załadowana do pamięci dwa razy.

1) Nie powinieneś patrzeć przez pryzmat języka, tylko mechanizmów obiektowych. Wówczas uniknąłbyś takich nonsensów jak redukowanie problemu diamentu do kwestii tego ile razy coś do pamięci się ładuje. Nie wszystkie mechanizmy obiektowe są wykorzystywane we wszystkich językach obiektowych, np. przytoczone mixiny.

2) Dla dziedziczenia masz prosty przykład, który powinien zilustrować Ci, że to mechanizm służący do innych celów niż kompozycja.

Masz zewnętrzną bibliotekę, której nie możesz modyfikować. Owa biblioteka dostarcza pewnej usługi via klasa Foobar w oparciu o kontrakt zdefiniowany dla Foobazów.
Chcesz reużyć funkcjonalności tej bilblioteki, ale nie masz Foobazów, albo są one kulawe.

class Foobar {
 Bar accept(Foobaz foobaz);
}

Dziedziczenie pozwala Ci osłabić/wzmocnić warunki kontraktu -> wprowadzasz CustomFoobaza i modyfikujesz zachowanie zgodnie z potrzebą. Używasz biblioteki.

3) Możesz zapomnieć o zachowaniach/strukturze i pomyśleć w kontekście typów:

class DayOfWeek {}
class Monday extends DayOfWeek {}
class Weekend extends Saturday,Sunday {}

JobDescription scheduleExecution(Weekend day); 

Budujesz sobie taki enum dla ubogich.

4) Przy wprowadzaniu dziedziczenia dobrze się zastanowić w nad relacjami ("Jest" vs "Ma") i czy są one stałe w czasie i nie wybierać dziedziczenia dla relacji "Ma", czy tam gdzie "Jest" zmienia się w czasie.

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