- Home /
Too subjective and argumentative
Events vs GetComponent for inter-script functionality
I have seen many questions here having answers that give example on how to use GetComponent
in order to modify a value in another script, or to call a function on another script. This is pretty much the same thing as passing a reference to another object during the contructor of your object, giving it full reign over that other object.
Now, I'm no programming expert but this bothers me because to me this seems like it's breaking encapsulation. Your script now has to be aware that the other script exists. This means your script cannot work independently of the other script. This is probably not a big deal on small projects, but I can see this leading to a giant mess with all scripts being intra-dependent on each other to the point where the project won't even compile should a single script be removed out of the equation.
I would have thought that a safer and more efficient way to make your classes work with each other would be to use events. This way, two classes that communicate with each other can exist without knowing of each other, and still compile and work (without the communication functionality) should one class be unaccessible.
So why is GetComponent
seems to be the most popular answer for questions related to "how do I make my script affect this other script?" type questions?
I would think GetComponent is more efficient first because it only requires a reference when the event needs an object, a delegate, also events seems liike a complicated approach as you would also needs a method to he called, well all in all GetComponent seems way easier to me which may be the reason of its popularity.
Having all variables and methods public
is also easy, but of course you understand what problems that leads to.
I should have been more clear in my question - apart from why GetComponent seems to be so popular, I also want to re-affirm that events is a safer method, and more maintainable in the long-term.
Fact is, your question is not really a question but more of a debate. GetComponent or event, public or private, carrot or potato. Then apart from your affirmation of long term maintainability, I still think it is more of a debate between easy use of reference or making things complex to avoid a possible problem which occurs in a case where the programmer is not careful enough.
Your event is only safe because you make it so. The pattern is to always check the event delegate for nullity. If you apply the same concept to reference you get the same result without all the overhead of event.
As for the public aspect of members, if your property is well designed, public properties are as safe as event.
So all in all, event is not a safer concept, it is what the programmer makes of it.
There's no point in checking for null if you can guarantee it won't ever be.
Answer by Jessy · Dec 17, 2013 at 05:03 PM
Understanding how to directly manipulate other objects is easy to teach, and it will technically allow you to do whatever you want. Unfortunately, a human being doesn't have the fluid intelligence to keep up with this practice on anything but a trivial amount of code. My opinion is that there are at least two main reasons you see so much of this:
It's succinct and does the job.
Many people in the community are enthusiasts who have learned bad practices from the examples you're talking about, and they don't know that there's a better way, so they teach the best they know how, which unfortunately isn't as good as it could be.
Follow this Question
Related Questions
The name 'Joystick' does not denote a valid type ('not found') 2 Answers
How to import the object from server to unity 2 Answers
Can someone help me fix my Javascript for Flickering Light? 6 Answers
Material doesn't have a color property '_Color' 4 Answers
Setting Scroll View Width GUILayout 1 Answer