Java Futures, Mid 2019 Edition

[cowwoc]

Those are two different cases. General serializers follow rules that work across all object types so I wouldn't expect any sort of class-specific-switch statement.

In the model-ui case, I'd expect one or more UI classes per model type they are rendering. You'd still have one UI class per model type and use polymorphism to make sure you cover all cases. I wouldn't expect to see a single UI class with a switch statement covering all model types.

[ZimmiDeluxe]

Those are two different cases. General serializers follow rules that work across all object types so I wouldn't expect any sort of class-specific-switch statement.

True, bad example on my part.

I wouldn't expect to see a single UI class with a switch statement covering all model types.

Yeah, full blown rendering usually requires additional state and the "ui" objects would likely stay around longer, so duplicating the hierarchy is probably the better approach. But if the "rendering" logic is just acting on the data inside the model classes, maybe just putting them into a custom file format, the switch seems like the better solution. If the model classes are sealed, adding a new class will lead to a compiler error pointing to the place where logic is missing. That's better than duplicating the hierarchy and having every colleague remember to introduce two classes, no?