Czym jest SOLID? - Standardowe Pytania Rekrutacyjne
HTML-код
- Опубликовано: 8 дек 2019
- 👉 DARMOWE SZKOLENIE ONLINE - Jak Zostać Programistą OD ZERA:
szkoladotneta.pl/zostan-progr...
👉 Wejdź do społeczności dla programistów : szkoladotneta.pl/discord
👉 Zapisz się na newsletter i dostawaj powiadomienia o nowych odcinkach:
szkoladotneta.pl
👉 Obserwuj mnie na Instagramie:
/ kajetan.duszynski
Drugie pytanie z serii #StandardowePytaniaRekrutacyjne.
Czym jest #SOLID?
Zapraszam na krótki opis wszystkich zasadach SOLID:
- Single Responsibility Principle (Zasada Pojedynczej Odpowiedzialności)
- Open/Close Principle (Zasada Otwarte/Zamknięte)
- Liskov Substitution Principle (Zasada Podstawienia Liskov)
- Interface Segregation Principle (Zasada Segregacji Interfejsów)
- Dependency Inversion Principle (Zasada Odwróconej Odpowiedzialności)
Wszystkie zasady zaprezentowane razem z przykładami w kodzie!
Obejrzyj i zwiększ swoje szanse na zmianę pracy.
Obiecana strona o Wujku Bobie:
Wiki - en.wikipedia.org/wiki/Robert_...
Blog - blog.cleancoder.com
Odcinek 002 - 09.12.2019
Kontakt: kajetan@moderndevelopment.eu
Blog: kajetanduszynski.pl
Instagram: / kajetan.duszynski
(przykłady z filmu pochodzą ze strony itnext.io/solid-principles-ex...) 
Наука
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
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."
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
2:05 Single Responsibility
4:55 Open / Close
7:32 Liskov Substitution
10:45 Interface Segregation
12:35 Dependency Inversion
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 :)
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 :)
Co za energia xd Spoko za effort (ok), daję like :)
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
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 )
jutro mam rozmowe akurat, pewnie zapamietam to trzy po trzy ale na farta sobie obejrzałem xD
fajnie wytłumaczone ale niestety drażni mnie głośna muzyka w tle w porównaniu do głosu...
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.
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 ?
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 :)
7:31 moje serucho zostało kupione!
💗
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.
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.
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ść
To tak jak w strzelectwie BLOS.
aj waj!
Skoro tak sądzisz :)
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 :)
wez kurwa glosniej tą muze
Ok :)
Ok :)