Callback to override methods in all child class

I have been looking at code architecture of Gesture Recognition system in unity-arcore-sdk GitHub repo. I found interesting architecture used in it.

BaseClass is an abstract class with virtual methods and registering method to the event in AnotherClass. ChildA and ChildB inheriting BaseClass and overriding method. AnotherClass triggers event when SpaceBar is pressed.

I see one downside - even if one of the Child gameobject is destroyed it is receiving callback. Maybe any way to destroy properly?

Is this legit? What's your opinion on it?

Thank you in advance.

Code (CSharp):

1. public abstract class BaseClass : MonoBehaviour
2. {
3.     void Start()
4.     {
5.         ConnectToEvent();
6.         //DisconnectToEvent();
7.     }
8.  
9.     void ConnectToEvent()
10.     {
11.         AnotherClass.Instance.OnEvent += Method;
12.     }
13.  
14.     void DisconnectToEvent()
15.     {
16.         AnotherClass.Instance.OnEvent -= Method;
17.     }
18.  
19.     protected virtual void Method() { }
20. }
21.  
22. public class ChildA : BaseClass
23. {
24.    protected override void Method()
25.    {
26.       Debug.Log("Child A: Method Called");
27.    }
28. }
29.  
30. public class ChildB : BaseClass
31. {
32.     protected override void Method()
33.     {
34.        Debug.Log("Child B: Method called");
35.     }
36. }
37.  
38. public class AnotherClass : MonoBehaviour
39. {
40.     public static AnotherClass Instance;
41.     public event Action OnEvent;
42.  
43.     void Awake()
44.     {
45.         Instance = this;
46.     }
47.  
48.     void Update()
49.     {
50.         if(Input.GetKeyDown(KeyCode.Space))
51.             if(OnEvent != null)
52.                 OnEvent();
53.  
54.     }
55. }

 

From that small code excerpt, it looks like that is the purpose of the base class having

DisconnectToEvent()

.

If a child knows that it is becoming redundant (has run out of fuel, health, too far from camera, etc.), then it needs to unregister itself from the event by calling that method.

 

Yeah got it can disconnect individual child class from event with

base.DisconnectToEvent();

 

It depends what you mean by "destroyed". In your code, something can be conceptually destroyed (e.g. an enemy space ship gets blown up and is, therefore, "destroyed").

However, C# is a managed language. That means it is in control of when/ how data is destroyed. The runtime guarantees you that, for as long as there are active references to an object, it will not get "destroyed" (i.e. deallocated and returned to the heap).

Yes, rather than have the event handler saying "if I am dead do nothing", you would want to say "as soon as I detect that I have died, then I call

DisconnectToEvent()

". That way, the event will no longer be called on "me".

 

Sounds reasonable.