Python i Django: Concrete inheritance

0:00Poprzednią lekcję skończyliśmy ze średnio

0:02użytecznym modelem produktu który raczej nie powinien być abstrakcyjny

0:09dlatego usunięty 5 neta klasę i uruchomimy migracja.

0:20Widzimy że teraz utworzyły się trzy modele

0:22utworzy się zarówno produkt książka jak i Bóg.

0:25I teraz bardzo ciekawe jest to co tam działo się pod maską.

0:38Spójrzmy tutaj.

0:44Trzeba wykonać migrację.

0:48Ot i tak mamy trzy tabele Mamy książkę i Bóg i produkt z nimi najpierw do książki.

0:57W książce mamy.

0:59Wskaźnik na produkt mamy b.

1:02Zero zimna i Bóg.

1:04Mamy spis treści i wskaźnik klimatu jeszcze na produkt w produkcie.

1:11Widzimy że są pola rodzica są te bazowe

1:13pola jest tytuł jest cena a w dzieciach jest wskaźnik na ten produkt.

1:20Działa to tak że

1:23w momencie jeżeli pobieramy i Bóg jako automatycznie robi wojna za pomocą

1:28tego wskaźnika do produktu wiek który wiersz konkretnie w produkcie które

1:34dokładnie dane dotyczą tego Buka tej książki którą my chcemy pobrać.

1:42Spróbujmy sobie utworzyć jakąś książkę utworzyć sobie.

1:47Jakiegoś buka i zobaczymy jak on się nam wyświetli.

1:59Jako książkę otworzymy dajmy na to.

2:04Harry'ego Pottera.

2:10Czy musimy być cena obok.

2:16Programowanie w jamie.

2:22Mamy tutaj stworzył się.

2:25Stworzyła się książka i stworzył się i Bóg.

2:27To jest ważne zwróćcie uwagę na to

2:30jakie metody Ester użyliśmy do tej zimy jeszcze raz w produkcie.

2:35Ester to produkt w bloku s t r to i Bóg a w książce to książka.

2:41Mamy tutaj coś takiego czyli wygląda tak jakby wszystko było poprawnie.

2:45Mamy przygotowaną jeszcze.

2:51Listę z produktami które korzystają z takiego seta i.

2:58Spróbujmy je uruchomić.

3:01Widzimy tutaj że mamy

3:02książkę mamy i Bóg czyli wygląda tak jakby wszystko było OK ale pokażę wam pewną.

3:11Bolączka która jest związana z tego typu

3:13dziedziczenia wejdziemy do

3:16listy produktów i zamiast tytułu spróbujmy wypisać reprezentację tego w formie.

3:25Okazuje się że zamiast buka i zamiast książki dostajemy dwa razy produkt.

3:30Tzn.

3:31Gdybyśmy mieli metodę GET Paris która w produkcie byłaby zdefiniowana inaczej niż

3:37w książce inaczej niż w roku dajmy na to byśmy inaczej liczyli jeżeli dostawa

3:42byłaby jakaś inna cokolwiek takiego to wtedy niezależnie od tego.

3:48Co byłoby wpisane w bloku co byłoby napisane w książce.

3:51Zawsze korzystamy z metod i zawsze

3:53korzystamy z properties of który jest w produkcie.

3:57Jest to.

3:59Tzw.

4:00problem Down castingu którego brakuje w domyśle tym secie Django.

4:08To rozwiązanie osobiście mi sprawdza się w

4:10przypadku kiedy mogę w bardzo fajny i dobry sposób wydzielić klasę rodzica i

4:17klasę dziecka gdzie nie zawsze muszę mieć np.

4:19dostęp do metod dziecka gdzie nie zawsze muszę mieć dostęp konkretnie do wszystkich

4:24a jeżeli mam taką potrzebę to po prostu robię inne zapytanie

4:28ewentualnie piszę metodę i w klasie rodzica odwołuje się do dziecka.

4:34Kolejnym problemem z tym rozwiązaniem które jest często poruszane jest brak

4:38kontroli nad nami to znaczy że jeżeli strona rośnie możemy

4:46odczuć drobne spowolnienie strony i nie mieć nad tym kontroli.

4:52Myślę jednak że takie problemy można rozwiązać za pomocą Kesha.

4:56Dlatego jeżeli wasze wymagania spełnia podział na dwie klasy w których

5:01jedna zawiera część funkcjonalności i druga zawiera drugą część i nie muszą one

5:06być używane zawsze jednocześnie to jest to dobre rozwiązanie.