Wpis z mikrobloga

@Volantie: polimorfizm jest OK, nie tak że zawsze zły. Jak masz metodę która ma robić 15 rożnych rzeczy w zależności od kontekstu - spoko.

Ale u mnie w pracy był taki magik co cały program napisał polimorficznie od A do Z, patrząc na kod nie mogłeś dowiedzieć się niczego. Szkoda że już go nie ma w firmie od kilku lat i on jeden wiedział jak to działa.
taki monopol, że poszedł gdzie indziej za wyższą kasę


@FLAC: no to jakby dostał większą kasę u was, to nikt by się teraz nie zastanawiał jak to działa.
@Patryk4: teraz wszystkie firmy tak działają, że po 4 latach szukasz nowej pracy nawet jak jesteś wymiataczem, bo po prostu tak łatwiej o skok zarobków. Niezależnie czy firma jest szczodra czy nie.
@FLAC: A'propos polimorfizmu. imo to dość spore uproszczenie.

Ja właśnie próbuję ogarnąć kod gdzie absolutnie nie ma polimorfizmu i wszystko jest naje*ane w jednej funkcji, która ma 3.2k LOC.

W każdą stronę można przegiąć. Za dużo abstrakcji - źle, za mało - też źle. ¯_(ツ)_/¯
@archvile: oczywiście, metoda albo funkcja na kilka tysięcy linijek kodu to zło. Zapewne dałoby się to podzielić na kilka mniejszych elementów.
@FLAC ok fajnie poznać takie info z drugiej strony, bo ja swiezynka jestem i myslalem ze takie wlasnie rzeczy są pożądane


@Volantie: W zadzie to: "Use the right tools for the job.", pewne wzorce czasami ułatwiają rozwiązanie problemu i zwiększają przejrzystość kodu a czasami są sztuką dla sztuki. Pewnie prosty serwis czytający dane z pamięci czujników temperatury można napisać na 50 klasach, pytanie tylko po co?

Natomiast polimorfizm wydaje mi się
Jak masz metodę która ma robić 15 rożnych rzeczy w zależności od kontekstu - spoko.


@FLAC: No z tym się nie zgodzę. Jak metoda ma robić 15 różnych rzeczy, to klasyczne i najlepsze rozwiązanie to enum + switch + delegacja do jednej z 15 metod robiących jedną rzecz.

Polimorfizm stosuje się wtedy, kiedy lista przypadków/kontekstów jest otwarta / nieokreślona / często się zmienia, a kod metody nie może być zmieniany, a
która ułatwia pisanie łatwych do rozszerzenia klas.


@Miesho: Jeśli *na pewno* nie wiesz wprost z wymagań projektu, że coś będzie wymagało rozszerzania, to należy założyć że nie będzie rozszerzane. Bo na 99% zajdzie konieczność rozszerzenia inaczej / w innym miejscu niż myślałeś, i Twoja pseudo-rozszerzalność tylko będzie bruździć i zaciemniać.
@Krolik: Problem w tym, że nie opisałem sytuacji w której chce rozszerzyć za 20 lat kod. Wydaje mi się, że napisałem o zaprojektowaniu interfaceu do kilku typów obiektów dziedziczących po jednej klasie bazowej. Umożliwi to wrzucenie wszystkich do jednej struktury danych i jedynie cykliczne wywoływaniu metod. Rozwiązanie wydaje mi się dość proste i nie wiem w czym ma zaśmiecać projekt.

Ponad to nie mam pojęcia jak założenie projektowe: "Jest szansa, że
Jest szansa, że w przyszłości będziemy używać większej ilości czujników


@Miesho: Na to musi odpowiedzieć biznes. Jeśli faktycznie chcesz otwierać API dla niezależnych dostawców czujników, to polimorfizm ma sens. Jeśli nie, a Ty kontrolujesz wszystkie czujniki, to większy sens ma zwykły enum + switch. Bo tym przypadku też można dodać nowy czujnik, tyle e trzeba będzie dopisać nową gałąź w switchu, ale to nie jest problemem skoro Ty masz kod źródłowy.