Observer pattern using static events

Question

I'm working on a game prototype: I have a Cell class which, given a mouse click on its collider, can raise an event that should be listened in two different modules: Camera and UI.

The Observer pattern implementation that I generally use follows this diagram:

But in this case it seems too tight and I don't see a simple way of adding such diverse observers explicitly to the Subject instance. So I tried to find a way to use the Observer pattern without the subject class keeping track of its observers, and the solution I found out is creating a C# static event raised from the Cell class:

public abstract class Cell : MonoBehaviour {

    public delegate void CellClikedHandler(Cell cell);
    public static event CellClikedHandler CellCliked;
    
    // ... 

    private void OnMouseDown() {
        CellCliked?.Invoke(this);
    }
}

public class ShowHideUI : MonoBehaviour {

    private void Awake() {
        Cell.CellCliked += ChangeUIVisibility;
    }

    public void ChangeUIVisibility(Cell cell) {
        //...
    }
}

public class CloseUpCamera : MonoBehaviour {

    private void Awake() {
        Cell.CellCliked += FocusCameraOnCell;
    }

    private void FocusCameraOnCell(Cell cell) {
        //...
    }
}

I have it currently working this way, but it doesn't feel right. I read here that it's particularly important with static events to unsubscribe so that instances don't get rooted, but I'm not sure of any further implications.

So I was wondering: which is the usual approach to implementing the observer pattern without explicitly adding the observers to the subject instance? If static events are generally used in this way, are there any downsides to it?

Answer 1

which is the usual approach to implementing the observer pattern without explicitly adding the observers to the subject instance?

One approach I could think of to implementing the observer pattern without the subject class keeping track of its observers is to use a message passing system or an event bus. This involves creating a central system that allows different objects to communicate without directly referencing each other. It allows for a more dynamic observer set, as new observers can be added or removed at runtime without the need to modify the subject class.

If static events are generally used in this way, are there any downsides to it?

While your approach of using static events to implement the observer pattern is valid in my opinion, there are indeed potential issues. One is that static events can be harder to manage and may lead to memory leaks if not properly handled. Since static events are not tied to a particular instance, they can be accessed from anywhere in the code, making it harder to track who is subscribing or unsubscribing. Another thing to consider is that static events can be prone to race conditions or other synchronization issues in multi-threaded environments.