So I've got a solution that contains a few big projects, which I'm trying to break down into smaller projects with more isolated responsibilities. This is a game I'm tinkering with -- I'm mainly a LOB developer and I think the principles are universal, so I'm hoping to learn something here.
The dependencies in some of the objects are a bit too tightly intertwined, and I'm hoping for some help on how to untangle them. Or maybe some sort of pattern or abstraction that might make them more manageable.
Ares.Core.World has classes in it like Creatures, Items, etc. All of them inherit from Entity, which is aware of what cell on the map it exist at. It accomplishes this by holding a reference to a Ares.Core.UI.MapControls.MapCell... And you can see that the wires are already getting crossed.
Ares.Core.UI.MapControls contains Map and MapCell, each of which contain Lists of creatures and items that they contain. MapCell also inherits from Ares.Core.World.Entity since that solved a few early problems very elegantly -- for instance, all Entities have inventory.
I would like to find a way to split UI and World out into seperate projects (Ares.World and Ares.UI) since UI and the overarching world should probably be seperate concerns. But as you can see, the way it is now the two projects would need to reference each other, and circular references are not allowed.
I'm wondering if there are any architectural patterns out there that might help in this situation. Thanks!