• FEATURED

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

## Why Unity engine encapsulate everything?

3 replies to this topic

### #1Elgauly  Members

Posted Yesterday, 03:46 PM

Is there any reason for Unity to encapsulate for example the x, y and z coordinates like this: gameObjectName.transform.position.x

and not just do this: gameObjectName.x or if you need the position in vector form that just do: gameObjectName.position

and another thing that I don't understand is why do I need to write GetComponent<componentName>() for every component that I need and not just  gameObjectName.component

Any reason to make things for complicated?

Edited by Elgauly, Yesterday, 03:46 PM.

### #2ApochPiQ  Moderators

Posted Yesterday, 04:43 PM

It's a combination of two things.

Your first example is a case where organization matters. Having a transform with a position is much more organized than keeping dozens of member variables on a single object.

The second example is where genericity has won out; in other words, in order to make things as general-purpose as possible, Unity has opted to take this route instead of other alternatives.

This is not really a situation where one approach is "right" and another is "wrong" - there are tradeoffs involved in both scenarios, and sometimes those are nice and sometimes they are pesky.
Wielder of the Sacred Wands

### #3kburkhart84  Members

Posted Yesterday, 09:07 PM

Besides what is mentioned above, I see it kind of as keeping "objects" as actual separate objects/classes.  If you only have a .x .y .z for position, then you don't have a nice object.  With an object, you can just use .position where it makes good sense.  For example, if you want to get the distance between two such positions, you need the x, y, and z for both, and as separate variables that makes 6 arguments to a function, or 3 if the function were called comparing "this" object to another.  But with everything all together in one object/class, you only need to send "position" to the function calls.  This is also great because "position" is a Vector3.  And Vector3 type variables are not only x, y, z values, but actual classes, with nice methods you can use.

About the second part, it is more for organization I think(not that Apoch is wrong, rather just adding on).  If you have a hierarchy of parent/child classes, with some methods on the parent where it makes sense, then you start getting into a lot of the purpose of OOP.  I'm no expert on the subject of course, but it makes sense.  By having a nice Monobehavior object/class, Unity can suddenly be really powerful.  Monobehavior includes the whole event system Unity is proud to have.  It also internally includes the stuff needed to be used in the editor, for the whole component drag & drop system, etc... that is included in Monobehavior.  Every class you make that is going to execute code(not just storage or similar) will be a child class of Monobehavior so that you can use all that Monobehavior has to offer.

*****

And my apologies there ApochPiQ.  I accidently downrated your post there, and it doesn't let me get rid of that.  That's my bad.

### #4Nypyren  Members

Posted Yesterday, 09:21 PM

why do I need to write GetComponent<componentName>() for every component that I need and not just  gameObjectName.component

Because you can create your own classes derived from MonoBehaviour and add those as components. Since fields and properties like gameObject.component have to be defined in the class, and C# does not let you add fields at runtime like some languages do, you would have to edit the GameObject source code to add any of your custom components (which would be a bad idea even if you could).

You can use extension methods, though I would not recommend it.

Edited by Nypyren, Yesterday, 09:25 PM.