Testy jednostkowe klasy dziedziczącej po klasie bazowej

Ever heard of the diamond problem?

Scala sobie z tym radzi :] https://alexn.org/blog/2018/02/12/in-defense-oofp.html#h2-2

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.

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.

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

Juhas napisał(a):

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

Wymień proszę

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.

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.

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.

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.

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/Multiple_inheritance#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.

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.

1. 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.

1. 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.