Testy jednostkowe klasy dziedziczącej po klasie bazowej

2

Ever heard of the diamond problem?

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

list.png

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.

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.

0

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

0
Juhas napisał(a):

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

Wymień proszę

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.

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.

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.

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.

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

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.

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

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