Is there a way to prevent the use of Update/FixedUpdate in child scripts?

Questions & Answers
1

From what I’m seeing, there’s nothing that can be done to prevent their use, but I might be missing something. We already have a system in place which handles Update/FixedUpdate-like functionality better suited to what we’re doing and would like to lock out their use solely to our base class. Since they’re not even inherited functions, neither sealed nor private new work, with the former not even compiling for obvious reasons.

Is there something that can be done to prevent those functions from being used or do we simply have to ensure that no one uses them throughout the project?

Edit:
To be more specific, this is the scenario.

class BaseClass : MonoBehaviour {
  void Update() { /* core logic */ }
  public virtual void Tick(float dT);
}

class ChildClass : BaseClass {
  void Update() { ... } // Do not want this to ever run, but it does.
  public override void Tick(float dT) { ... } // This is where code should go.
}
2

Hey there,

sealed is definitely the answer, you may need a third class in the mix

See examples here: http://msdn.microsoft.com/en-us/library/aa645769(v=vs.71).aspx

I used the example from the above link to prevent overriding of a method, like this:

class A : MonoBehaviour
{
	public virtual void F() {
		Debug.Log("Class A, Method F");
	}
	public virtual void G() {
		Debug.Log("Class A, Method G");
	}
}
class B: A
{
	sealed override public void F() {
		Debug.Log("Class B, Method F");
	} 
	override public void G() {
		Debug.Log("Class B, Method G");
	} 
}
class C: B
{
	override public void G() {
		Debug.Log("Class C, Method G");
	} 
	override public void F() {
		Debug.Log("This will not work, gives error");
	} 
}
3

If I understood correctly, you’re trying to implement dirty updates and don’t want your objects’ scripts to be using Update() on their own.

Since Unity only allows Monobehaviours attached to GameObjects, what we did in a similar scenario is invert the control of things: instead of having a Monobehaviour script attached to a GameObject, we have a non-Monobehaviour script, with a reference to the GameObject, and we call our own DirtyUpdate() function and perform whatever we want on the GameObject.

However, not having a Monobehaviour will also prevent you from receiving all Unity events such as collisions, so keep that in mind.

The GameObject would not have any scripts attached to it. If you need Unity Editor control, you can use ScriptableObjects and also add references to it.

It’s not the cleanest solution but it works.

However, this does not prevent anyone from creating a Monobehaviour and attaching to the GameObject.

On the other hand, you can have a safety check (if you’re working on a large team, for instance, and are receiving scripts from multiple developers), that performs some tests on all the prefabs through Resources and check if GetComponent is true, then throw an exception.