Je plussoie le sujet!
Je suis Dev Unity et j'ai des questions similaires aux tiennes. On m'a conseillé ce livre, mais il me paraît assez gros, et je ne suis pas sûr qu'il soit vraiment approprié dans la dev de Jeux Vidéo. Si quelqu'un a des listes de Design Patterns pour les Jeux Vidéo, je suis prenneur.

De mon point de vue de Dev (et de ce que je comprend de ton projet), je te conseillerais mettre un singleton dans la class de la Barre action, qui serait appellé dans le code de la Porte, dans la fonction Start() , à la création de la Porte. Cela implique bien sur que tu n'ais qu'une seule instance de Barre d'action.

Code de la barre d'action

public static BarreAction mInstance;
public static BarreAction instance{ get{return mInstance;} }

// Use this for initialization
void Awake () {
mInstance = this;
}

Code de la Porte

// Use this for initialization
void Start() {
BarreInstance = BarreAction.instance;
}

On peut également imaginer que le code de la Porte instancie une Barre d'action, et que c'est la Porte qui va générer chaque bouton et callback dans la Barre d'action. Pour moi c'est à la Porte de générer et de contrôler tous les composants.

J'ai trouver une super liste de Design Patterns Unity c# sur Reddit:
https://www.reddit.com/r/Unity3D/comments/1nb06h/unity_design_patterns_and_concepts_looking_for/

En ce qui concerne ta question, je suis en train de regarder plus en détail comment les Events et les Delegates fonctionnent de manière à ne pas te dire de bêtises.

M'étant posé la question depuis pas mal de temps, et ayant reçu des cours sur Unity 3D, je peu répondre qu'avec mon expérience qui n'est pas une science exact ^^.

Pour moi il y a deux pratique sur Unity :
Soit tu programme avec de la composition =>
- Un GameObject à un script qui lui permet d'avoir de la vie par exemple (ce script pourra être donnée a un autre GameObject ayant lui aussi de la vie)

Ou alors tu programme (comme on me la appris) avec de la POO :
Le principe c'est que tu as des manager en singleton qui se parle entre eux avec des évènements.
Je m'explique : j'ai un GameManager, qui vas instancier un LevelManager qui lui vas se charger de gérer le niveau, par exemple en ce qui concerne ta porte :
La porte émet un évent lorsqu'on lui clique dessus, elle dit "On ma cliquer dessus", le LevelManager reçoit cette évènement et gère ce qu'il doit faire en fonction (dans ton cas il ouvre une pop-up qui fait sa sauce)

Et ainsi de suite ^^.

Je ne m'exprime peut être pas super bien si tu as des questions n'hésite pas

Oui pour le singleton.

Moi on m'a dit de faire du "Top-Down" je m'explique.

En gros les grosses classes on le droit d'appeler des méthodes de classes en dessous d'elle mais pas le contraire :
GameManager a le droit d'appeler une méthode de DoorManager (par exemple) mais pas le contraire (ça doit se faire par appelle d'évènement)

Ce que moi j'appelle les event c'est les méthodes déléguées si tu veux.
Du coup si tu veux suivre ce que je viens de dire(comme j'ai dit j'ai pas la science exact et mes profs non plus) t'es objets qui collide ne doivent pas appeler une méthode du GameManager mais ils doivent émettre un event.

Comment ce faire de manière simple : On nous a montrer une méthode pour émettre un message facilement des petits éléments de la scène jusqu'au manager.
En gros dans ta hiérarchie tu as un objet GameManager ou LevelManager qui as le script, a l'intérieur tu instancie tes petit éléments de sorte qu'il soit enfant du GameObject (dans la hiérarchie Unity et non enfant de manière POO attention ^^) De ce fait tu peu emmètre en faisant SendMessageUpward (je suis pas sur de la fonction mais ça ressemble ^^)

A voir si ça te va mais va pas tout cassé ton architecture actuelle pour faire ce que je te dit hein ^^, ce n'est qu'une façon de faire parmi d'autres