I have to model a store with all kinds of articles. The user has to be able to filter these articles by type, price, ... . The store would contain a list of Article objects.
I've been stuck on whether to implement the Article class with a type field or to subclass new articles from the Article class.
Biggest problem I see when implementing with inheritance is the filtering by type. I'm going to have to lookup which type my derived objects in the Article list are, which would either require that every derived class has a getType() function or I'd have to use reflection to get the class name and work with that, both of which kinda defeats the purpose of inheritance. To access the specific fields of each derived class, i'd first have to filter by type and then downcast all Article objects of the correct type to that type to be able to access their specific fields. I have no idea if this is considered a good design.
On the other hand, I had the idea to have the Article class have a type field and a Map to represent it's data. I would then have to ensure that the necessary (key, value) pairs are added to the map for each different type and maintain an ENUM for the fields of each different type. Article would become an incredibly flexible class this way so I'd have to make sure my factory method's for each type would ensure the right pairs are added to the info map depending on the type. It would also require more discipline from the coder using the Article class to only access the map keys that are defined for that particular type.
I could also just keep different derived objects in different lists in the shop, but then I'd have to add a list every time I'd add a new article which isn't good for maintainability.
Any extra arguments for any of the possibilities that could help me decide would be appreciated.