W filmie jest błąd. Jeżeli chodzi o zasadę L Liskov. 8:25 "Pod klasę pochodną można było podstawić klasę bazową." (??) Zakładając, że moja klasa, w której dziedziczę po klasie X dodaję nową metodę np: make(). To kiedy przy wywołaniu tej metody podstawię obiekt klasy bazowej program się wysypie i nie jest to złamanie tej zasady. Zasada brzmi odwrotnie. Pod obiekt bazowy mogę podstawić klasę dziedziczącą, nie odwrotnie. Taka zasada nie miałaby sensu bo wychodziłoby , że klasy dziedziczące nie mogą wprowadzać żadnych nowości w swoim ciele. "Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów."
Wiem wiem :) już to słyszałem. W nowym filmiku jest, ale cichsza więc nie przeszkadza. Mam nadzieję, że tam już Ci będzie odpowiadać :) ale dzięki za feedback
Wspaniały materiał! Przeczytałem już z 5 artykułów nt. SOLID i dopiero te przykłady i wyjaśnienia pozwoliły mi to zrozumieć. Tłumaczenie SOLIDa bez przykładów jest pomyłką.
Dobrze omówione na przykładach. Ja, który nie mam dużo narazie wspólnego z C# - bo dopiero zaczynam - byłem wstanie mniej więcej załapać temat. Tylko jedyne co rozprasza to za głośna muzyka w tle.
Hint na przyszłość (bo już chyba za późno by poprawić teraźniejszy materiał), to podkład muzyczny jest za głośny w stosunku do głosu. Musiałem słuchać z wytężoną uwagę, żeby miejscami zrozumieć. Jeśli będziesz więcej nagrywał, to mikrofon pojemnościowy lub przynajmniej krawatowy byłby super, bo słychać echo specyficzne dla pomieszczenia. A poza tym to w końcu zrozumiałem o co chodzi z Liskov Substitution. Mam wrażenie, zę wcześniej człowiek uczył się na pamięć tych głupich definicji, których nikt na 100% nie rozumie ;)
Masz klasę Post jej jedyną odpowiedzialnością jest dodawanie postów - ma metodę CreatePost(), a gdzie byś umieścił metody EditPost, ewentualnie DeletePost ? Czy jakbyś umieścił je w klasie Post, to było by już złamanie zasady pojedynczej odpowiedzialności, czy jeszcze nie ?
Czy w zasadzie Open-Close zadeklarowanie metody klasy bazowej jako virtual samo w sobie nie jest modyfikowaniem istniejącej klasy, a zatem złamaniem zasady? Czy jednak taka deklaracja jest traktowana jako rozszerzenie, bo chyba poza tym, że dopiszemy virtual i można po tym dziedziczyć (i nadpisywać w klasie potomnej), to nic się nie zmienia? Extension Methods też są przykładem stosowania tej zasady? Jakie są jeszcze inne rozszerzenia? Szkoda, że tylko po jednym prostym przykładzie podałeś. :P
Przykład z SPR: logowanie błędu. Przeniesiono logowanie do oddzielnej klasy- metody. Ta metoda log robi dwie rzeczy, loguje poprzez db.logerror oraz i zapisuje content exceptiona do pliku metoda writealltext. Czy to nie jest właśnie złamanie zasady srp?
wg mnie jak najbardziej. żeby trzymać się tej zasady trzeba by ostro polecieć z ilością klas, pytanie się nasuwa czy w serwisie też powinniśmy trzymać się tej zasady? wg mnie zasada dobra ale trzeba stosować ją kiedy będzie to przydatne :)
Muzyka potrzebna uważam jest ok. To nie techno,można się skupić jednakże można nieco sciszyc. Zainwestuj w lepszy mikrofon. Material rzetelny.Kokejne propozycje:omów wzorce ale tylko te które się obecnie korzysta. Dinozaury możesz jedynie wymienić. Dodatkowo omów z czasem dobre praktyki.W co warto zainwestować w jakie kierunki programowania?Czy WPF,czy MVC czy może inne technologie.
Tak, właśnie testuje różne poziomy głośności mam nadzieję, że w końcu się uda dobrać odpowiedni :) Mikrofon to największy problem. Coś tam kupiłem, ale nie jestem pewny czy będzie lepszy. Zobaczymy. Dzięki za propozycję. Na pewno będzie realizowana :)
Mnie ciekawi temat przekazywania danych z bazy danych poprzez schemat xml do np. raportu DevExpress-owego, gdzie wtedy nie mamy DataSource a mamy DataSourceSchema. Był mega problem dla mnie znalezieniem czegokolwiek. Do tej pory wiem tylko, że jest w designerze DataSourceSchema = resources.GetString("$this.DataSourceSchema"); i mogę podejrzeć kolumny we właściwościach , a skąd to się tam wzięło, jak to jest przekazywane to nie mam pojęcia.
Wiesz co, nie do końca wiem bez kontekstu, o czym mówisz. Tym bardziej że DevExpressem już dawno się nie bawiłem. Ale jakbyś wskoczył na grupę na FB facebook.com/groups/nauczsiedotneta to możesz opisać ten problem i się wspólnie zastanowimy.
Absolutnie nie. Dwie oddzielne metody do read i edit są jak najbardziej ok. Jedyne o czym musisz pamiętać to żeby obie wykonywały tylko jedną czynność (odczyt/edycja) analogicznie jak w create :) Co do edita to można pokusić się o zrobienie upserta czyli stworzenie nowego postu albo zedytowanie jeśli już taki istnieje.
To zależy, odczyt i zapis to 2 oddzielne rzeczy nie mające ze sobą wiele wspólnego. Należy sobie odpowiedzieć na pytanie: Czemu mam edytować klasę, która zapisuje dane do bazy danych skoro chcę zmienić tylko sposób odczytu. Klasa, która ma metody read, edit, write narusza SRP. Czy w przypadku prostego rozwiązania CRUD jest to problem? Absolutnie nie, rozdzielenie zapisu od odczytu mogłoby jedynie skomplikować cały system. Jeśli jednak w klasie tworzone są tworzone agregaty za pomocą skomplikowanych zapytań to wtedy należy pomyśleć o rozdzieleniu zapisu od odczytu np. stosując CQRS - martinfowler.com/bliki/CQRS.html
Aj trochę przekombinowałeś moim zdaniem. Dlaczego CRUD narusza SRP? Nie do końca mogę się z tym zgodzić. Fakt, że to trochę kwestia interpretacji definicji, ale tworzenie oddzielnych klas dla Create, Read, Update, Delete w "standardowym" modelu byłoby zdecydowanie nadmiarowe i trzeba wtedy zejść o poziom niżej i traktować każdą metodę jako odpowiedzialną za jedną rzecz. Zawsze traktujmy wszelkie zasady ze zdrowym rozsądkiem, bo mają nam one pomóc, a nie utrudnić sprawę. Co do CQRS to jak najbardziej się zgodzę, bo przy bardziej skomplikowanych projektach elegancko można rozdzielić wszystkie odpowiedzialności, ale też nie wprowadzajmy tutaj zbytniego zamieszania. Na CQRS też przyjdzie czas :)
@@szkoladotneta Dlatego napisałem, że przy CRUD'zie nie jest to problem a wręcz powinno się upraszczać - encja na twarz i pchasz (jak to mówi Sławomir Sobótka). W przypadku bardziej rozbudowanych zapytań lub konstruowania agregatów z różnych źródeł danych lepiej oddzielić zapisywanie od odczytywania.
W filmie jest błąd. Jeżeli chodzi o zasadę L Liskov. 8:25 "Pod klasę pochodną można było podstawić klasę bazową." (??) Zakładając, że moja klasa, w której dziedziczę po klasie X dodaję nową metodę np: make(). To kiedy przy wywołaniu tej metody podstawię obiekt klasy bazowej program się wysypie i nie jest to złamanie tej zasady. Zasada brzmi odwrotnie. Pod obiekt bazowy mogę podstawić klasę dziedziczącą, nie odwrotnie. Taka zasada nie miałaby sensu bo wychodziłoby , że klasy dziedziczące nie mogą wprowadzać żadnych nowości w swoim ciele.
"Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów."
Prędkość x 1.5 i fajnie się ogląda :)
Mówisz, że powinienem szybciej mówić? :)
@@szkoladotneta that's right baby ;-) dzięki ;;)
Mi wystarczyło 1.25 xD
2:05 Single Responsibility
4:55 Open / Close
7:32 Liskov Substitution
10:45 Interface Segregation
12:35 Dependency Inversion
Ta muzyka w tle niepotrzebna :/
Wiem wiem :) już to słyszałem. W nowym filmiku jest, ale cichsza więc nie przeszkadza. Mam nadzieję, że tam już Ci będzie odpowiadać :) ale dzięki za feedback
Mi z kolei ta muzyka odpowiada, miło się słucha.
Muzyka jest ok ale jest za głośna, mnie rozprasza, nie mogę się skupić.
Wspaniały materiał! Przeczytałem już z 5 artykułów nt. SOLID i dopiero te przykłady i wyjaśnienia pozwoliły mi to zrozumieć. Tłumaczenie SOLIDa bez przykładów jest pomyłką.
Miód na moje oczy :) dziękuję
Fajnie się to ogląda
Co za energia xd Spoko za effort (ok), daję like :)
Dobrze omówione na przykładach. Ja, który nie mam dużo narazie wspólnego z C# - bo dopiero zaczynam - byłem wstanie mniej więcej załapać temat. Tylko jedyne co rozprasza to za głośna muzyka w tle.
Mnie tez muzyka rozprasza, za glosno.
Ja wiem :) ale teraz już z tym nic nie zrobię :) Od tamtej pory wiele się nauczyłem i w najnowszych materiałach jest już znacznie lepiej :)
Dobre omówienie. Dzięki
Jak dla mnie na poczatek to mega fajne. I to nie tylko na rozmowy ale rowniez jak to wyglada w praktyce.
Cieszę się, że Ci się podoba :)
Hint na przyszłość (bo już chyba za późno by poprawić teraźniejszy materiał), to podkład muzyczny jest za głośny w stosunku do głosu. Musiałem słuchać z wytężoną uwagę, żeby miejscami zrozumieć. Jeśli będziesz więcej nagrywał, to mikrofon pojemnościowy lub przynajmniej krawatowy byłby super, bo słychać echo specyficzne dla pomieszczenia. A poza tym to w końcu zrozumiałem o co chodzi z Liskov Substitution. Mam wrażenie, zę wcześniej człowiek uczył się na pamięć tych głupich definicji, których nikt na 100% nie rozumie ;)
Tak, tak. Ten filmik to początki moich zmagań z dźwiękiem. Później jest znacznie lepiej (choć też nie zawsze :P )
7:31 moje serucho zostało kupione!
💗
fajnie wytłumaczone ale niestety drażni mnie głośna muzyka w tle w porównaniu do głosu...
Masz klasę Post jej jedyną odpowiedzialnością jest dodawanie postów - ma metodę CreatePost(), a gdzie byś umieścił metody EditPost, ewentualnie DeletePost ?
Czy jakbyś umieścił je w klasie Post, to było by już złamanie zasady pojedynczej odpowiedzialności, czy jeszcze nie ?
Czy w zasadzie Open-Close zadeklarowanie metody klasy bazowej jako virtual samo w sobie nie jest modyfikowaniem istniejącej klasy, a zatem złamaniem zasady? Czy jednak taka deklaracja jest traktowana jako rozszerzenie, bo chyba poza tym, że dopiszemy virtual i można po tym dziedziczyć (i nadpisywać w klasie potomnej), to nic się nie zmienia?
Extension Methods też są przykładem stosowania tej zasady? Jakie są jeszcze inne rozszerzenia?
Szkoda, że tylko po jednym prostym przykładzie podałeś. :P
Przykład z SPR: logowanie błędu. Przeniesiono logowanie do oddzielnej klasy- metody. Ta metoda log robi dwie rzeczy, loguje poprzez db.logerror oraz i zapisuje content exceptiona do pliku metoda writealltext. Czy to nie jest właśnie złamanie zasady srp?
wg mnie jak najbardziej. żeby trzymać się tej zasady trzeba by ostro polecieć z ilością klas, pytanie się nasuwa czy w serwisie też powinniśmy trzymać się tej zasady? wg mnie zasada dobra ale trzeba stosować ją kiedy będzie to przydatne :)
Muzyka potrzebna uważam jest ok. To nie techno,można się skupić jednakże można nieco sciszyc. Zainwestuj w lepszy mikrofon. Material rzetelny.Kokejne propozycje:omów wzorce ale tylko te które się obecnie korzysta. Dinozaury możesz jedynie wymienić. Dodatkowo omów z czasem dobre praktyki.W co warto zainwestować w jakie kierunki programowania?Czy WPF,czy MVC czy może inne technologie.
Tak, właśnie testuje różne poziomy głośności mam nadzieję, że w końcu się uda dobrać odpowiedni :)
Mikrofon to największy problem. Coś tam kupiłem, ale nie jestem pewny czy będzie lepszy. Zobaczymy.
Dzięki za propozycję. Na pewno będzie realizowana :)
Dla mnie za głośna. W takich naukowych rzeczach, tutorialach, gdy trzeba się skupić, muzyka powinna być cichutko.
jutro mam rozmowe akurat, pewnie zapamietam to trzy po trzy ale na farta sobie obejrzałem xD
Mnie ciekawi temat przekazywania danych z bazy danych poprzez schemat xml do np. raportu DevExpress-owego, gdzie wtedy nie mamy DataSource a mamy DataSourceSchema. Był mega problem dla mnie znalezieniem czegokolwiek. Do tej pory wiem tylko, że jest w designerze DataSourceSchema = resources.GetString("$this.DataSourceSchema"); i mogę podejrzeć kolumny we właściwościach , a skąd to się tam wzięło, jak to jest przekazywane to nie mam pojęcia.
Wiesz co, nie do końca wiem bez kontekstu, o czym mówisz. Tym bardziej że DevExpressem już dawno się nie bawiłem. Ale jakbyś wskoczył na grupę na FB facebook.com/groups/nauczsiedotneta to możesz opisać ten problem i się wspólnie zastanowimy.
Masz koszulkę założoną na lewą stronę? ;)
Nie :) to chyba po prostu wyjątkowo sprany nadruk :P tylko u mnie na kanale - sama prawda i naturalność
czy w przypadku SRP dodanie np. read/edit zaburzyłoby już tą zasadę?
Absolutnie nie. Dwie oddzielne metody do read i edit są jak najbardziej ok. Jedyne o czym musisz pamiętać to żeby obie wykonywały tylko jedną czynność (odczyt/edycja) analogicznie jak w create :)
Co do edita to można pokusić się o zrobienie upserta czyli stworzenie nowego postu albo zedytowanie jeśli już taki istnieje.
To zależy, odczyt i zapis to 2 oddzielne rzeczy nie mające ze sobą wiele wspólnego. Należy sobie odpowiedzieć na pytanie: Czemu mam edytować klasę, która zapisuje dane do bazy danych skoro chcę zmienić tylko sposób odczytu. Klasa, która ma metody read, edit, write narusza SRP. Czy w przypadku prostego rozwiązania CRUD jest to problem? Absolutnie nie, rozdzielenie zapisu od odczytu mogłoby jedynie skomplikować cały system. Jeśli jednak w klasie tworzone są tworzone agregaty za pomocą skomplikowanych zapytań to wtedy należy pomyśleć o rozdzieleniu zapisu od odczytu np. stosując CQRS - martinfowler.com/bliki/CQRS.html
Aj trochę przekombinowałeś moim zdaniem. Dlaczego CRUD narusza SRP? Nie do końca mogę się z tym zgodzić. Fakt, że to trochę kwestia interpretacji definicji, ale tworzenie oddzielnych klas dla Create, Read, Update, Delete w "standardowym" modelu byłoby zdecydowanie nadmiarowe i trzeba wtedy zejść o poziom niżej i traktować każdą metodę jako odpowiedzialną za jedną rzecz.
Zawsze traktujmy wszelkie zasady ze zdrowym rozsądkiem, bo mają nam one pomóc, a nie utrudnić sprawę.
Co do CQRS to jak najbardziej się zgodzę, bo przy bardziej skomplikowanych projektach elegancko można rozdzielić wszystkie odpowiedzialności, ale też nie wprowadzajmy tutaj zbytniego zamieszania. Na CQRS też przyjdzie czas :)
@@szkoladotneta Dlatego napisałem, że przy CRUD'zie nie jest to problem a wręcz powinno się upraszczać - encja na twarz i pchasz (jak to mówi Sławomir Sobótka). W przypadku bardziej rozbudowanych zapytań lub konstruowania agregatów z różnych źródeł danych lepiej oddzielić zapisywanie od odczytywania.
Dobry materiał ale strasznie cicho nagrany. Musiałem na słuchawkach odtwarzać.
Hej. To był jeden z pierwszych moich filmów. W nowszych jest znacznie lepiej :)
aj waj!
Skoro tak sądzisz :)
To tak jak w strzelectwie BLOS.
wez kurwa glosniej tą muze
Ok :)
Ok :)