Likes to keep system mechanics separate from UI no matter what he is doing.
Things you learn in gamedev after 2 years. Or things you learn in mobile on your first day.
Inventory has no idea how it's being displayed on a screen, if you make it care, you will make the code too complicated.
Inventory should have a list of items. You want add item, remove item, they have to always work. They shouldn't have error codes, they should have associated functions can remove/can't remove.
Wants inventory to know about equipment slots, and equip/unequip have equivalent have equip/can't unequip.
There should be an abstract class Storage, of which Inventory, Equipment, Lootbag and whatever else is an implementation.
Storage has virtual methods, the implementations override these methods.
To move items between those, you can have a Broker class. It'll rely on these virtual methods alone.
Of course the UI watches for changes. The widgets don't need to know anything about the storage class itself.
Instead, the storages emit objects of class UpdateOperation, which the UI knows about, and which is also abstract of the Storage implementation.
This way, everything is decoupled.
Inventory component, now that it is complete, can be added to containers.
Except you don't always want containers to act like inventory. E.g. the inventory may be a map, an in-game container may be an array.
Same applies to merchants, creature inventory, etc.
Anyway,.. is there a more boring subject?
Who needs this? People who know how to code already know it. People who don't, don't need this.
Also, this is the tip of the iceberg. When you start making usable items in Unreal or create generic properties to hang onto items, like "equippable" with an exposed equip-slot parameter, that's where the good stuff begins.