Home/ Questions/Q 4624668
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T03:09:42+00:00

So I’ve got a solution that contains a few big projects, which I’m trying

  • 0

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, but I’m mainly a LOB developer and I think the principles are probably universal, and I think I could 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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    So, your World classes – Creatures, Items, etc. – they all need something from MapCell.

    Can you reasonably create an interface (or several) that represent what the World Entities need? So that the Entities only need an implementation of that interface?

    This would be the first step to decoupling the two. Perhaps obviously, none of the method signatures or properties of this interface can include classes from the UI project. It should be defined with standard types or custom types in a library both World and UI reference (e.g., Ares.Core).

    Then, in the UI project define implementations of the interface(s) that encapsulate a MapCell and provide what is needed to the World Entities.

    Use your IoC of choice to provide the implementation where it is needed, depending on how you get the MapCell, you may need to also layer on a Factory.

    Without more details of your particular needs it’s hard to be specific, but I think this approach in general should be workable.

    • 0