How to get rid of static game world classes in a project?

Question

.NET

Good day. The unity project has a game world (a list of star systems, objects in them, a subsystem for controlling moves / game date). The problem is that now it is represented by several static classes and this has begun to create problems (there is no uniform deserialization of the world as an object, it is impossible to throw it at the mercy of the GC and create a new one without crutch cleaning all members of these classes, besides, they are not cleared in the unity editor when Play Mode is stopped and as a result there may be unpredictable behavior of unit tests that run in the remaining game world, etc., etc.).
Of course, if you take and remove static, it will be like this:

I created a WorldContext, threw these same WorldCtl, StarSystems, etc. into it. But how now to bring it to all this crowd of people? Of course, you can simply create a static field of the CurrentWorldContext type, since it is unlikely that you will need to simultaneously simulate several worlds. But still, the fact that entities that are logically related to another world can suddenly turn to the current one is not encouraging, but a crutch. Passing it to the constructors of all-all-all ... too much boilerplate, which is also bad, and how much memory is wasted.
Maybe there are already known ways to solve this problem?
I thought about this method of solving the problem: introduce an interface with one property

public interface IWorldContextProvider
{
  WorldContext WorldContext { get; }
}

And implement it "in a chain" (i.e., say, the implementation of this property for the ship's equipment will return the same property of the parent ship, etc.). But maybe there is a simpler solution?

Answer 1

Well, in general, what you are looking for is called Dependency Injection (DI). Passing to constructors everywhere-everywhere-everywhere by hand is one of the implementations, almost the most primitive. Surely there are better implementations in Unity, I suggest you google it yourself.

Answer 2

The problem is that you are accessing objects that have not yet been created (if you remove static). So you need to create objects. If the settings are standard there, then you can throw them all into something and then take them from there, as an already created element, if the settings are changeable, then you should make methods for changing and call them in some update.
To put it simply: if an object is on the stage before the game starts, then it is considered created - you only need to transfer its instance and then use it at your discretion.

Answer 3

As I understand you have a problem in Static classes, in my opinion the Singleton pattern will help you . That is, your classes will not be static (they may even inherit from MonoBehaviour), but there will be an Instance variable that will allow them to be accessed in a static context. This pattern, too, of course, should not be abused, but in my opinion it will be a relatively painless way out.