[ToJestNiepojete]

Czy dobrą praktyką jest przechowywanie / transferowanie struktur danych po wspólnym typie bazowym? Niech to nawet będzie koło, prostokąt, trójkąt i ich typ bazowy figura. Dostaję te obiekty (właściwie to struktury) w liście jako figury i chcę wypisać ich szczegóły na ekranie. Muszę przefiltrować listę i zrobić instanceofa (lub wprowadzić pole typu), aby dokonać rzutowania na właściwy obiekt, bo dopiero wtedy będę miał dostęp do specyficznych pól danej figury (promień koła, kąt trójkąta). Więc w tym przypadku nie ma zachowania, które byłoby polimorficznie wykonywane. Tutaj mam tylko listę pól do wyświetlenia, przygotowaną praktycznie pod widok, czyli te obiekty to takie DTOsy pod dany ekran aplikacji. Czy w takim przypadku powinienem je dostawać pod wspólnym typem, czy może powinny to być trzy oddzielne listy (koło, prostokąt, trójkąt) i wtedy bez żadnego rzutowania?

#programowanie #java (pytanie dość ogólne, bez ścisłego powiązania z technologią)

[E.....e]

@ToJestNiepojete: wizytator?

[Whiskeyjack29]

@ToJestNiepojete: instance of w takim wypadku to zupełny anty pattern, przecież każda figura może decydować w jaki sposób prezentuję szczegóły o sobię, albo programujemy obiektowo i wykorzystujemy polimorfizm albo proceduralnie
i wtedy inaczej definiujemy nasze struktury danych i też nie ma w tym nic złego ale takie zastosowanie to złamanie zasady LSP. Oczywiście instanceof/is samo w sobie jest przydatne w metaprogramowaniu czy tworzeniu rozwiązań frameworkowych, więc samo w sobie nie jest

[Saly]

@ToJestNiepojete: tak, choć OOP szury mogą cię zjechać, bo nie znają życia poza swoją javą. W nowej javie masz nawet specialny feature do tego https://www.baeldung.com/java-sealed-classes-interfaces , który pierwotnie wywodzi się z języków funkcyjnych.

[Whiskeyjack29]

@Ewentualnie: wizytator to ciekawe rozwiązanie tego problemu, które pozwala odwrócić problem "kiedy pisać obiektowo a kiedy proceduralnie" ale z mojego doświadczenia 90% programistów go niestety nie zna.

[Whiskeyjack29]

@Saly: Trochę absurdalne rozwianie na coś co rust już dawno rozwiązał w elegancki sposób

[Saly]

@Whiskeyjack29: to design rodem ze scali czy kotlina. Prawdopodobnie to najsensowniejsza implementacja jak masz już język z klasami/interfejsami i chcesz dopchnąć ten ficzer w prosty sposób. Z ciekawostek to nowa scala będzie miała sum typy jak w ruście https://dotty.epfl.ch/docs/reference/enums/adts.html , więc na pewno to rozwiązanie z sealed classes jest uważane za słabe

[ToJestNiepojete]

@Whiskeyjack29: Ale że figura ma decydować jak ma się prezentować na interfejsie użytkownika, gdzie mam z góry przygotowane pola w layoucie, pod które chcę jedynie wpisać daną wartość? Toż nie wypisuję stringa tylko mam oddzielne komponenty widoku pod każdą figurę i chce to ładnie zaprezentować.

@Saly: Sealed klasy robią tylko autocasta (przynajmniej w kotlinie), więc ifologia zostaje nadal. No i ja bym chyba przy tym rozwiązaniu się opowiedział.

@Ewentualnie:

[Saly]

Sealed klasy robią tylko autocasta (przynajmniej w kotlinie), więc ifologia zostaje nadal. No i ja bym chyba przy tym rozwiązaniu się opowiedział.

@ToJestNiepojete: oczywiście, chciałem tylko pokazać, że to też rozwiązanie i polimorfizm/dziedziczenie to nie jedyny sposób na rozwiązanie tego problemu

[E.....e]

@ToJestNiepojete: nie, musisz dodac metode visit(visitator){visitator.visit(this);}

[ToJestNiepojete]

@Ewentualnie: A kurde, faktycznie. Już chyba nie myślę pod wieczór...

[Whiskeyjack29]

@ToJestNiepojete: To w takim razie czemu na front wysyłasz obiekty logiki? No chyba że twoje klasy mają tylko pola i gettery i settery to zdradzę ci wtedy sekret - programowanie obiektowe ma sens tylko dlatego że chcemy robić użytek z polimorfizmu, w innych wypadkach szkoda zachodu na coś co i tak nie ma sensu. Te obiekty nie mają ze sobą nic wspólnego i wykorzystanie dziedziczenia w tym przypadku jest utrudnianiem sobie

[Whiskeyjack29]

Mogę mieć hierarchię figura ->trójkąt/prostokąt/okrąg bo moja logia potrzebuje liczyć pola i obwody tych figur niezależnie od ich typu, albo chciał bym mieć metodę draw() bo projektuję program do rysowania figur na ekranie. Hierarchia figura ->trójkąt/prostokąt/okrąg przestaję mieć sens w przypadku potrzeby wyświetlenia właściwości tych figur bo każdy ma inne okrąg promień, prostokąt 4 boki, trójkąt 3 boki.

[ToJestNiepojete]

@Whiskeyjack29: Przecież od początku pisałem o strukturach danych / DTOsach. Jak inaczej reprezentować strukturę niż obiektem? To po prostu ValueObject do pokazania.

Te obiekty nie mają ze sobą nic wspólnego i wykorzystanie dziedziczenia w tym przypadku jest utrudnianiem sobie roboty

Dokładnie to zagadnienie poruszam w swoim pytaniu. Czy jest sens trzymać te struktury pod jednym typem, czy lepiej przekazać je jako 3 oddzielne listy. A że chcę je wyświetlić na ekranie

[Whiskeyjack29]

@ToJestNiepojete: W projekcie na studia/małej aplikacji? Wszystko jedno, chyba bym przekazał oddzielne tablice do oddzielnych komponentów odpowiedzialnych za dane figury i nie tworzył żadnej hierarchii dziedziczenia. W dużym projekcje który ma być łatwo rozszerzalny? Kompletne odseparowanie kontrolek od wiedzy o tym co wyświetlają, tylko jak dane typy danych mają być wyświetlane i jak potencjalnie edytowane, w językach Java, C# jest to możliwe przy rozsądnym wykorzystaniu refleksji i konwencji. Przy naprawdę dużym

[Whiskeyjack29]

Wizytator to też ciekawe rozwiązanie chociaż nie jestem przekonany co do robienia wizytatorów pod UI bo nagle wszystkie twoje DTOsy będą miały metodę visit bo front ich potrzebuję, generalnie trzeba rozważyć + i -