koobas.hobune.stream
Why isnt the enabled property part of an interface?
Is there any known rationale to not having the enabled property of some bheaviours and components not abstracted in an interface?
I'd very much like to be able to create an array that can can contain renderers, ridigbodies, behaviour, etc knowing they all implement some "IEnable" interface, meaning they all have an enabled interface.
//Dream example:
List<IEnable> enableList ;
enableList.Add( rendererObj) ; //renderers have the enabled property
enableList.Add( ridigBodyObj ) ; // ridigbodies do too.
enableList.Add(scriptObj) ; // and so do scripts.
//and a few more I can't recall right now.
foreach( var current in enableList ) current.enabled = false ;
If you are thinking the Component class can do the trick, It can't. It does not have an enabled interface.
Disclaimer: This is a software design question. This is not a question meant to solve an immediate practical problemn. It is meant to fill a knowledge gap, and hopefully be accessible thru this website to anyone that may use such knowledge for a more practical purpose.
maybe because nobody thought that disabling each component single handedly ins$$anonymous$$d of disabling the whole gameobject, basically being the same for all components, would make sense. maybe there's also performance considerations involved.
but to be honest, an engine engineer would have to answer this to be sure.
Opinion/Discussion Qs are better in the Forums. I'd specify whether you want a work-around. $$anonymous$$ight also look for an official Unity FeatureRequest.
$$anonymous$$y opinion: it's a matter of perspective. $$anonymous$$any native C#/Java users think there should be an interface for everything that can have one. $$anonymous$$y feeble software engineering is from Stroustrup, who says you shouldn't make things you only think there might be a use for.
Right, even the property has the same name, it's actual function differs from case to case. Not all Behaviours can be enabled that's why the Behaviour class as well as the Component class does not have an enabled property. You could go crazy with all possible properties, like "color" or "texture".
Technically (perhaps pedantically) speaking, all behaviours have the enabled property. https://docs.unity3d.com/ScriptReference/Behaviour.html
$$anonymous$$oreover, I cannot think of any component with the enabled property that does not conceptually do the same in each case (very much expected behavior every time). Colliders stop colliding, scripts stop running Update(), RigidBodies stop interacting with physics, renderers stop rendering.
Wanting to disable and enable "enableable" features within a game object without needing to know their concrete type. That example I gave is a possible use case, it should not take much imagination to see how this use case would appear in a real project.
If you have a frozen character, and there is an event that 'enables' its rigidbody, a script that lerps a glow, a particle effect, an animator component, and an audio source, a collider. $$anonymous$$aybe an event is supposed to trigger them all. Not only would an interface make the code cleaner, but It would make it extensible (Open/Closed principle).
$$anonymous$$aybe it should indeed be in the forums. it is more of a discussion thing.
