In a 2D game, buildings can be upgraded with modules; Those modules can be bought in a shop.The shop is represented by a stereotyped grid of icons, each icon representing a buyable module. When the mouse hovers an icon, the name a description of the associated module appear in a popup.Currently, the modules are model objects extending an abstract Module class wearing the following data:The name of the moduleA description of what it does to your buildingThe icon used to display the module in the shop's gridAlso, some f(building)-like methods to actually modulize the building...At the beginning of the game, the shop is provided with a list of modules. When applying a module to a building the f(building) methods are called on the bought module. Thus, even not using the Singleton pattern, each *Module class is instantiated only once.I'm conscious that this design is not really optimal:First, a module, a model object, embeds its own icon, a view representation.And more important: a module is stateless because the same object can be applied on several buildings (possibly of different players); in order to be stateful, a module would have to wear a [building] => data map... I don't know why, but I have a bad feeling about this solution...Question time:Is the [building] => data map effectively a bad solution?If so, what's the best way to solve the statefulness pitfall I'm encountering?Subsidiary one: also, it would be more MVC-compliant if each model object didn't have to wear an image...
How to modelize items in a shop (like LoL, Dota, ...) the MVC way?
design;object oriented design;mvc;game development