W 43. odcinku DevTalka czas zająć się tematem, który niejawnie przewijał się wielokrotnie, ale nigdy… wprost.
Akcja: BLOGvember! Post nr 5.
W listopadzie w każdy roboczy poranek na devstyle.pl znajdziesz nowy, świeżutki tekst. W sam raz do porannej kawy na dobry początek dnia.
Miłej lektury i do przeczytania jutro! :)
Rozmawiam z Łukaszem Olbromskim. Zmagaliśmy się swego czasu z Sharepointem przy wspólnym projekcie, odkrywaliśmy NOWE. Sporo się razem nauczyliśmy. Teraz, po latach, i powrocie Łukasza z wieloletniej emigracji do Danii… usiedliśmy przy jednym internecie i pogrążyliśmy w rozmowie. Na Twitterze: @LukaszOlbromski.
Podywagowaliśmy o wzorcach projektowych. Zastanawiamy się co to właściwie są wzorce, po co je wymyślono i jak programiści do nich podchodzą. Podzieliliśmy się swoimi refleksjami odnośnie najciekawszych i najbardziej przydatnych wzorcach. Nie zabrakło również tematu antywzorców, co dla niektórych może okazać się najbardziej przydatną częścią rozmowy.
Wiecie co robić: słuchawki na uszy i PLAY! Za rekomendację na iTunes także się nie obrażę :).
Miłego słuchania!
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki:
- książka Gang of Four “Design Patterns: Elements of Reusable Object-Oriented Software”: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8
- seria postów Teda Newarda: http://blogs.tedneward.com/patterns/
- post o Service Locator: http://devstyle.pl/2016/02/11/antywzrorzec-service-locator/
- DevTalk o CQRS z Udim Dahanem: http://devstyle.pl/2015/04/13/devtalk14-cqrs-with-udi-dahan/
- moja prezentacja o CQRS: https://www.youtube.com/watch?v=itQOsr9pmsg
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Odcinek o szacowaniu czasu realizacji zadania/funkcjonalności/projektu musi być!!! Będę słuchać!!!
OHDEV,
Futurist jak nic :). Ten temat jest już umówiony, wkrótce nagranie.
Mam jedno ale, jeżeli chodzi o temat “Singleton’a” w kontenerach DI. To, że w niektórych kontenerach nazwano ową funkcjonalność Singleton Scope, nie czyni tego klasycznym singletonem, bardziej mapuje się to na wzorzec Monostate.
Różnica:
Singleton, Implementacja zapewniająca tylko jedną instnację danego typu o charakterze globalnym. Praktycznie każdy klient wie, że dany obiekt jest singletonem. -> ble
Monostate: Implementacja, która zapewnia jednakowy stan(bądź jego brak) dla wszystkich utworzonych, gdzie żaden klient nie zdaje sobie sprawy z owej sytuacji. W przypadku gdy mamy DI po bożemu, czyli rozwiązujemy zależności przez konstruktor, to klient komponentu nie ma zielonego pojęcia kiedy, i dlaczego został on utworzony i klienta nie powinno to obchodzić. Najczęściej są to klasy, które nie mają pół(czyli stanu), a jedynie zbiór metod o wspólnym kontekście. Przykłady, które ja praktycznie zawsze rejestruje jako SingleInstance:
-DateTimeProvider,
-proste walidatory,
-fabryki, mappery
-etc
Kamil,
Masz rację jeśli chodzi o nomenklatuję, jednak nie widzę sensu w konfigurowaniu bezstanowych obiektów jako singletony. Instancjonowanie klas w .NET jest ekstremalnie tanie, to kwestia przesunięcia wskaźnika “wolnej pamięci” – zalet (szczególnie wydajnościowych) nie zaobserwujemy w 99% przypadków, a dochodzi komplikacja w postaci specjalnej konfiguracji kontenera.