Nadmierna inżynieria :). Na początku była jedna klasa i robiła co miała robić. Na końcu już nawet nie liczę ile powstało klas :). W inżynierii jest jedna podstawowa zasada, coś ma działać. Ja bym w ogóle nie podchodził do zmian, które tu przedstawiłeś. Klasa robiła co ma robić, przy dodawaniu nowego typu, dodaje tylko typ i nowego switcha i zajmuje się implementacją innych funkcjonalności w sofcie. Tu będę się srał z refaktoryzacją, kombinował, marnował czas na nadmierną inżynierię, a nic to w praktyce nie posunie rozwoju produktu do przodu. Ten kod nie będzie działał lepiej, ani szybciej, ani nie ma żadnego praktycznego bonusu z tej zabawy. Po prostu bawię się w teoretyczne rozważania, które nic mi nie dają. Reasumując z jednej klasy która robiła co do niej należy powstało ileś tam klas. Co uzyskałem? Nic, oprócz większej objętości kodu, zmarnowania czasu i na dodatek jeżeli chcę coś teraz zmieniać to muszę skakać po klasach i szukać. Także edukacyjnie owszem ma to sens, generanie też ma to sens, ale niby dlaczego ma się przestagać jakiś zasad jak SOLID i tak dalej. Wszystko ma swoje wady i zalety i nie widzę powodu trzymania się jakiś zasad, bo ktoś coś tam sobie wymyślił. Na jego argumenty ja mogę podać kontrargumenty.
Kurcze jestem już dosyć doświadczonym programistą i ten wzorzec jak wiele innych już wielokrotnie wykorzystywałem ale zaciekawiła mnie ta playlista że pokazujesz wzorce na przykładach i "chciało" Ci się wstawić właśnie taki kruczek że liczba parametrów nie jest sobie równa. Ja mam niestety tendencje że no jak tworzę wzorzec i nadal coś łamie to mnie skręca i próbuje czasem na siłę stworzyć coś idealnego a pewnie utrudniam. To podsumowanie trochę otworzyło mi oczy że coś jest kosztem drugiego i czasem trzeba z tym żyć 😁
Cześć. Na początek napiszę, że tworzycie bardzo wartościowy content. Na samym końcu usunięta konstrukcja 'switch' jednak w wielu przypadkach gzieś ta decyzja o wstrzyknięciu srategii. która jest zależna od `type` musi zapaść. I najprowdopodobniej będzie to po prostu w innym miejscu.
Więcej takich materiałów! W ogóle gdzie twój Patronite? PS: Nie chodzi tutaj nawet o sam wzorzec strategii, który pewnie wielu oglądających zna, ale o sposób opowiadania o programowaniu. Poruszyłeś tu przynajmniej kilka wątków, które początkującemu programiście mogą dać do myślenia i zrozumieć jak w ogóle podchodzić do programowania. Na moich studiach takich rzeczy było bardzo mało, więcej gadania o konkretnych wzorcach, algorytmach, wydajności, zarządzaniu pamięcią itd. Ale jak podchodzić do refactorowania kodu żeby zrobić to sprawnie i nie zasypać się błędami to już nikt nie uczył.
Dzięki :) Planujemy przeplatać filmiki tłumaczące konkretne wzorce, filmikami tego typu. Tak by pokazać z jakimi decyzjami tak de facto mierzymy się na co dzień.
Nadmierna inżynieria :). Na początku była jedna klasa i robiła co miała robić. Na końcu już nawet nie liczę ile powstało klas :). W inżynierii jest jedna podstawowa zasada, coś ma działać. Ja bym w ogóle nie podchodził do zmian, które tu przedstawiłeś. Klasa robiła co ma robić, przy dodawaniu nowego typu, dodaje tylko typ i nowego switcha i zajmuje się implementacją innych funkcjonalności w sofcie. Tu będę się srał z refaktoryzacją, kombinował, marnował czas na nadmierną inżynierię, a nic to w praktyce nie posunie rozwoju produktu do przodu. Ten kod nie będzie działał lepiej, ani szybciej, ani nie ma żadnego praktycznego bonusu z tej zabawy. Po prostu bawię się w teoretyczne rozważania, które nic mi nie dają. Reasumując z jednej klasy która robiła co do niej należy powstało ileś tam klas. Co uzyskałem? Nic, oprócz większej objętości kodu, zmarnowania czasu i na dodatek jeżeli chcę coś teraz zmieniać to muszę skakać po klasach i szukać. Także edukacyjnie owszem ma to sens, generanie też ma to sens, ale niby dlaczego ma się przestagać jakiś zasad jak SOLID i tak dalej. Wszystko ma swoje wady i zalety i nie widzę powodu trzymania się jakiś zasad, bo ktoś coś tam sobie wymyślił. Na jego argumenty ja mogę podać kontrargumenty.
Kurcze jestem już dosyć doświadczonym programistą i ten wzorzec jak wiele innych już wielokrotnie wykorzystywałem ale zaciekawiła mnie ta playlista że pokazujesz wzorce na przykładach i "chciało" Ci się wstawić właśnie taki kruczek że liczba parametrów nie jest sobie równa. Ja mam niestety tendencje że no jak tworzę wzorzec i nadal coś łamie to mnie skręca i próbuje czasem na siłę stworzyć coś idealnego a pewnie utrudniam. To podsumowanie trochę otworzyło mi oczy że coś jest kosztem drugiego i czasem trzeba z tym żyć 😁
Ale piękna duża kaka :)
Cześć. Na początek napiszę, że tworzycie bardzo wartościowy content. Na samym końcu usunięta konstrukcja 'switch' jednak w wielu przypadkach gzieś ta decyzja o wstrzyknięciu srategii. która jest zależna od `type` musi zapaść. I najprowdopodobniej będzie to po prostu w innym miejscu.
solidny konkret ;)
czemu ten kanał ma tak malo wyswietlen?
Super kontent, szkoda że tak mało znany kanał :(
Więcej takich materiałów! W ogóle gdzie twój Patronite?
PS: Nie chodzi tutaj nawet o sam wzorzec strategii, który pewnie wielu oglądających zna, ale o sposób opowiadania o programowaniu. Poruszyłeś tu przynajmniej kilka wątków, które początkującemu programiście mogą dać do myślenia i zrozumieć jak w ogóle podchodzić do programowania. Na moich studiach takich rzeczy było bardzo mało, więcej gadania o konkretnych wzorcach, algorytmach, wydajności, zarządzaniu pamięcią itd. Ale jak podchodzić do refactorowania kodu żeby zrobić to sprawnie i nie zasypać się błędami to już nikt nie uczył.
Dzięki :) Planujemy przeplatać filmiki tłumaczące konkretne wzorce, filmikami tego typu. Tak by pokazać z jakimi decyzjami tak de facto mierzymy się na co dzień.
Kiedy kolejne filmy?
Powoli wracamy do życia po intensywnych półtora miesiącach :) W ciągu 2 najbliższych tygodni powinien pojawić się film na kanale.