❔ Design question
Hi! I'm a beginner and I'm having trouble finding a decent design for this toy application I'm making.
So, at a high level, I have a list of items, and I'd like to let the user filter the items and only display the relevant ones. So far so good, but the complexity comes from the fact that the items in my case come in many variants (let's call them A, B, C, etc. for the sake of the discussion). Item variants are definitely related in terms of the domain, but they are fairly unrelated when it comes to the data itself. So, A might have a little bit in common with C, B might have a little in common with A, etc. There's very little that is common to all the variants.
So, all the items should live in the same list to be filtered, but the filter might refer to a field that doesn't even exist on a specific variant (in that case it should be excluded). Furthermore, once the items have been filtered, it should be possible to select a particular item and see all the data specific to that variant. So I need some sort of downcasting mechanism.
I'm sorry if this sounds confusing, well I am confused :/
10 Replies
how many fields are we talking, you could even flatten the classes and not have types
is there a reason for not doing so?
I guess having one uber class with all the possible fields makes sense in terms of querying.
is there a reason for not doing so?"once the items have been filtered, it should be possible to select a particular item and see all the data specific to that variant" It seems to me like it would be very tedious/error-prone without having specific types for each variant. Maybe I'm mistaken though, I'd like to hear your thoughts on the matter to be clear, even if two items have the same field, that field might be displayed differently based on the variant of the item.
I don't know how your data is stored internally
But you could have an interface with a function to retrieve a specified field (based on some kind of key or ID)
Each item type could implement the interface differently and return appropriate defaults when the field is not relevant to that type
This would allow the different types to be managed in the same way while also enabling specific differences between them
Yeah I think that's a good idea
one uber class with all the possible fieldsuber for me would mean >200 fields
kind of gets both best of both worlds
data and presentation are different layers, even
As a rule of thumb I like to work with the type system and make things as composable as possible. To me a type with 200+ optional fields is absolutely crazy and unmaintainable.
data and presentation are different layers, evenI'm not sure what that means in practice in this case, but to me the problem is structured like I like @exokem 's suggestion because it allows me to keep my actual data layer intact while also providing an interface for the query layer.
it means that i wouldn't use data for business logic for presentation, because presentation has different logic, so there could be the need to remap stuff
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.