To się nazywa dobre wytłumaczenie interfejsu - budowanie po kolei - od zwykłego dziedziczenia po klasę abstrakcyjną po interfejs, tego brakowało w innych kursach.
W jakim celu się używa interfejsy, skoro i tak trzeba sobie wszystko samemu zaimplementować (nie wiem czy użyłem odpowiedniego słowa). Nie szybciej byłoby od razu implementować bez używania interfejsu?
w kontekscie tego przykładu, załóżmy, że dla tych 3 różnych typów plików (excel, word i powerpoint) masz za zadanie skompresować plik i wysłać go jako załącznik mailem. I jakbyś do tego zadania podszedł bez tego wspólnego interfejsu dla tych 3 typów? Musiałbyś utworzyć w jakiejś klasie, conajmniej 3 metody, dla każdego typu z osobna, a ich implementacja byłaby taka: pobrałbyś nazwę pliku, wczytał do pamięci, skompresował i wysłał skompresowaną wartość emailem. Ponadto konsument (miejsce w kodzie gdzie wywoływałbyś wysłanie tego pliku emailem), musiałby w jakiś sposób na podstawie klasy danego pliku wywołać odpowiednią metodę A z drugiej strony jeśli wydzielisz wspólny interface IFile, to w klasie która zajmuję się wysyłaniem emaili, teraz zamiast 3 metod per każdy tym pliku, masz jedną, która jako parametr przyjmuje abstrakcje IFile. Czyli de facto ta klasa nie wie jaki konkretnie plik będzie wysyłać, dzięki czemu osiągniemy luźne powiązanie (loose coupling) I w takim podejściu konsument nie zwraca uwagi na to jaki konkretnie typ pliku musi wysłać emailem, po prostu wywołuje metodę do której przekaże obiekt implementujący interface IFile Także przy takim podejściu kod jest bardziej 'elastyczny', bardziej rozszerzalny i reużywalny
@@FullstackDeveloperPL a planujesz robić jakaś serię czy coś, z pisania jakiegoś większego projektu? I czy masz w planach przerabianie w poradnikach Formsów itd?
To się nazywa dobre wytłumaczenie interfejsu - budowanie po kolei - od zwykłego dziedziczenia po klasę abstrakcyjną po interfejs, tego brakowało w innych kursach.
Fajne bo krótkie, treściwe i na temat!
W jakim celu się używa interfejsy, skoro i tak trzeba sobie wszystko samemu zaimplementować (nie wiem czy użyłem odpowiedniego słowa). Nie szybciej byłoby od razu implementować bez używania interfejsu?
w kontekscie tego przykładu, załóżmy, że dla tych 3 różnych typów plików (excel, word i powerpoint) masz za zadanie skompresować plik i wysłać go jako załącznik mailem.
I jakbyś do tego zadania podszedł bez tego wspólnego interfejsu dla tych 3 typów?
Musiałbyś utworzyć w jakiejś klasie, conajmniej 3 metody, dla każdego typu z osobna, a ich implementacja byłaby taka: pobrałbyś nazwę pliku, wczytał do pamięci, skompresował i wysłał skompresowaną wartość emailem.
Ponadto konsument (miejsce w kodzie gdzie wywoływałbyś wysłanie tego pliku emailem), musiałby w jakiś sposób na podstawie klasy danego pliku wywołać odpowiednią metodę
A z drugiej strony jeśli wydzielisz wspólny interface IFile, to w klasie która zajmuję się wysyłaniem emaili, teraz zamiast 3 metod per każdy tym pliku, masz jedną, która jako parametr przyjmuje abstrakcje IFile. Czyli de facto ta klasa nie wie jaki konkretnie plik będzie wysyłać, dzięki czemu osiągniemy luźne powiązanie (loose coupling)
I w takim podejściu konsument nie zwraca uwagi na to jaki konkretnie typ pliku musi wysłać emailem, po prostu wywołuje metodę do której przekaże obiekt implementujący interface IFile
Także przy takim podejściu kod jest bardziej 'elastyczny', bardziej rozszerzalny i reużywalny
@@FullstackDeveloperPL czy to samo się do metod?
@@papkin8902 tak, dokładnie :p
@@FullstackDeveloperPL a planujesz robić jakaś serię czy coś, z pisania jakiegoś większego projektu? I czy masz w planach przerabianie w poradnikach Formsów itd?
@@papkin8902 tak, na pewno na kanale pojawią się materiały z tworzenia aplikacji webowych w ASP.NET
Przyjemnie wytłumaczone, ale wolałabym wysłuchać bardziej obszerny materiał, a nie tylko wstęp do zagadnienia.