A common solution to building a model of a system which consists of many items of different types is to create a modular system, where each module is responsible for particular type. For example, there will be module for wombats WombatModule:IModule, where IModule interface has methods like GetCount() (to find number of wombats) and Update() (to update all wombats' state).
More object-oriented approach would be to have class for every item type and create an instance for every item. That will make class Wombat:IItem with methods like Update() (to update this one wombat).
From code perspective difference is negligible, but run-time is significantly different. Module-oriented solution is certainly faster: less object creation, easier to optimize operations common for all wombats.
Problems come when number of types and modules grow. Either you lose most of performance advantage because each module only supports several items, or modules' complexity grows to accomodate for slightly different items of one general type - say, fat and slim wombats. Or both.
At least once I've seen it degrade into poor state when all WombatModule does is keep a collection of hidden Wombat objects and run their methods in loop.
When performance is less of a problem than long-term development, can you identify any architectural reasons to use modules instead of per-item objects? May be there's another possibility I'm missing?