well what i was describing is more of a component based architecture that doesn’t make use of much inheritance.
the base class would do nothing more than the behavior common to all inventory items like setting up its display (static mesh, UI display, etc) and interfacing with a pickup system, for example.
any additional behavior could be handled with actor components. for instance if you have food that should spoil over time, you put that into the data table. then when the food item is created, it knows to add the Food Spoilage component.
You could make a subclass to handle that to but you lose flexibility (you might not need the flexibility, which is perfectly valid).
what i mean by lose flexibility is if you decided that you also have wood which can rot and that is essentially the same behavior as food spoiling, then if you have to make Wood Log derive from Food class that becomes very confusing. But if you just have a component for “measure how long thing has been alive” and a component for “report when item has reached end of lifespan” and these both just read values from data table, now you can cover a broad range of items without getting locked into anything very specific.
lots of ways to skin the cat, I am just adding these ideas here, not to suggest that they beat other approachs in any particular case. Have to look at the project with a wide lens and see what makes most sense.