[htfhere]

#programowanie #java robicie switcha, w którym casy są oparte o przekazany enum (np. VehicleType). Ponad switchem tworzycie zmienną Vehicle vehicle (Vehicle to interfejs) i jeszcze jej przypisujecie do niej żadnego obiektu. W zależności od tego jaki jest enum ( VehicleType.Car, VehicleType.Boat itd) to taki obiekt zostanie utworzony, np vehicle = new Car(). Implementujecie tworzenie obiektu dla wszystkich typów enum. Oczywiście w takiej sytuacji obiekt może nie zostać utworzony (np. ktoś doda nowy rodzaj w enumie i puści to w tego switcha) dlatego w switchu trzeba utworzyć opcję default. Co teraz wklepać w default, żeby kod był elegancki? throw new RuntimeException("VehicleType: + vehicleType + " is not supported") ?

[wqdqweff]

@htfhere: można, rozsądne rozwiązanie.

[ChestNoot]

@htfhere: Ten wyjątek poleci na UI czy rylko do logow ? A może po prostu defending coding i wyklucz możliwość wpuszczenia typu którego nie supportujesz

[Waffenek]

@htfhere: Rzucanie runtime exceptiona jest raczej standardowym rozwiązaniem. W javie 12 doszło switch expression co trochę cywilizuje pisanie takiego kodu.

[Edhendil]

@htfhere: IllegalArgumentException pewnie bardziej by pasowało ale ogólnie podejście z wyjątkiem unchecked jak najbardziej poprawne.

[B.....r]

@htfhere przy okazji obczaj sobie factory pattern, bo chyba to chcesz osiagnac :P

[htfhere]

@ChestNoot: tylko do logów a ogólnie to najlepiej jakby testy wykluczały możliwość puszczenia na produkcję kodu, który może wyrzucić ten wyjątek ;) co rozumiesz pod pojęciem defending coding?

[htfhere]

@BlueBear: no właśnie zastanawiałem się nad tym i chyba faktycznie skorzystam z factory ;)

[htfhere]

@wqdqweff: @Waffenek: @Edhendil: Dziękuję za odpowiedź :)

[B.....n]

@Waffenek: Ten switch expression bardzo przypomina mi to co jest w Kotlinie, a mianowicie "When", tylko że w Kotlinie nie daje się case

[jak5z]

@htfhere: proszę nie rób switch-case do takich rzeczy, jak masz już tego biednego enuma to możesz zrobić go nie anemicznego i w nim zawrzeć tworzenie obiektu i zrobić z niego factorkę
Ale naprawdę jak robisz switch-case do tego to wiedz że coś poszło nie tak z Twoim kodem

[htfhere]

@jak5z: ok to jak spróbuję tu zaimplementować factory pattern to jak mam wybrać, którą implementację chcę utworzyć?

[jak5z]

@htfhere: Ja jestem zwolennikiem factory na enumach powyżej javy 8 - można to zaimplementować funkcjonalnie i wymusza to przy dodaniu enuma, implementacje funkcji fabrykującej.
Minus jest ten że gdy masz za dużo logiki w enumach to robią sie problemy ale pytanie czy enum jest anemiczny cz nie.
Wg pojawia się duże pytanie czy potrzebny jest Ci ten enum?

[htfhere]

@jak5z: nie jest potrzebny, mógłbym np. przekazywać wartość w postaci stringa i w oparciu o to wybierać implementację, ale core problemu by się nie zmienił, czy mam rację? Widzę, że jesteś bardzo dobrze zaznajomiony z pisaniem czystego kodu, czy miałbyś może gdzieś "pod ręką" kod z przykładowym funkcjonalnym wzorcem fabryki na enumach? Chętnie rzuciłbym okiem na kawałek dobrego kodu.

[jak5z]

@htfhere: https://stackoverflow.com/questions/17581310/using-enum-for-factory-in-java-a-best-practice https://stackoverflow.com/questions/2163414/enum-factory-style-method
Niestety nie mam kodu którego mogę udostępnić, ładnie byłoby

enum Type {
A(() -> new A()),
B(() - >

[GrzechG]

Psttern Visitor na interfejsie do Vehicle. Wszystko będzie eleganckie i nowe typy będą musialy mieć dodana odpowiednią implementację (kompilator to wymusi)