koobas.hobune.stream
Fundamental difference between Class and Object ?
I thought "classes" are kind of the "blueprints" for "objects".
But there's a class called "Object", so when we talk about "Object" it could mean "Blueprint of an Object" and "an Object itself" at the same time?? (Freaky!! O_o )
For example:
The "AnimationCurve"-Class does not derive from the "Object"-Class.
It has a Constructor which creates "an Animation Curve".
Is that newly created Animation Curve not an Object since the "AnimationCurve"-Class does not derive from the "Object"-Class?
Or is it an Object, but of the Class "AnimationCurve" (and not of the Class "Object")?
Or is it somehow an Object of the Class "Object" anyway? (If so, is that the way a Constructor works? Turning a non-Object-Class into an Object-Class-Object...? o_O )
So is there a difference between "Object" when talking about
the ObjectOrientedProgrammingConcept of "Object" and
the "Object"-Class defined in the API?
__
"Of the Class XY" is my next problem... When do you say an Object is "of some-or-another class"?
Does something necessarily need to be constructed from a Class to be "of Class XY"?
And/Or is a GameObject "of Class XY" once it has the Script which contains "Class XY" attatched to it?
Or is it somehow enough to have all the Attributes and Abilitys of Class XY to be "of Class XY"?
__
(also see http://answers.unity3d.com/questions/1955/not-every-class-in-the-api-is-derived-from-the-object-class-so-what-are-they for Jashans excellent answer on my very closely related topic that got me to ask this slightly different question in the first place)
Thanks & Greetz, Ky.
Your original understanding that classes are "blueprints" for objects was actually quite right. See my answer to "Not every class in the api is derived from the object class so what are they" for a better understanding ;-)
Your understandable confusion indeed comes from the fact that "object" in terms of object oriented program, has a different meaning than the unity api specific type called UnityEngine.Object.
I usually prefer to not talk about 'objects', but instead refer to them as 'instances', so things get less confusing when you actually want to talk about UnityEngine.Object.
Regarding your second question, Unity's design philosphy is based around "has a" instead of "is a". In other game engines, you might find a class hierarchy like this:
EnemySoldier -> Soldier -> Humanoid -> Unit -> MovableThing -> BaseObject.
(-> indicating an "inherits from" relationship)
A lot of people these days think that having deep "enheritence chains" like that are usually not the best solution to the problem at hand. Instead a lot of people, including the unity engine, are using a more component based approach:
GameObject has:
- EnemyBehaviour
- SoldierBehaviour
- MovableThingBehaviour
It's a "has a" relationship, instead of a "is a" relationship. It makes it easier to shuffle things around while you're developing. One thing to note is that nothing is stopping you from mixing the two. For instance if you have 3 different MonoBehavouir classes, that share a lot of code, you can use enheritence and put that shared code into a base class.
There's a large amount written on this topic, if you google for "composition versus inheritance" you'll find plenty for several rainy sundays.
Thank you! So I'm not plain stupid, yay!! =D The "has a" thing is an insightful point and I'm recently beginning to really see the merits of composition over pure inheritance... however, I still see the "is a"-term used a lot on the forums as well as in the tutorials (if I'm not mistaken) when it's a script of that class attatched to a GameObject... so can I assume that this is often due to blurry use of ter$$anonymous$$ology?
A class is a template to create objects (or instances) of that class.
A class can inherit from another class, which means that instances from the former class are also instances from the latter.
For example, the class "Cat" may inherit from a class "FurryCreature". If "Igor" is an instance from the class "Cat", then "Igor" is also an instance from the class "FurryCreature".
In most object-oriented programming languages, you will find a particular class named "Object", from which all classes inherit. Therefore, every object is an instance of the class "Object".
In unity, in order for an object to be "of class XY", the object needs to have the "XY" script or component attached to it, or needs to have been explicitly instantiated in some script.
Object-oriented programming is a deep and rich field, which builds itself on basic but very abstract concepts. In order not to get lost, a good entry point is almost mandatory, otherwise it is easy to mix up concepts and get confused. I suggest the wikipedia article on POO, which is lenghty but covers the subject :
"you will find a particular class named "Object", from which all classes inherit. Therefore, every object is an instance of the class "Object"." --- Yes, that had been my understanding. But Unity appeared to not stick with that, wich was my problem... (see also my other question in the link above) --- As I'm lucky to have a Java-Programmer at my hand to explain basic OOP-concepts to me, I flinched from reading that extensive Wiki-article. But having looked into it now, I have to admit it's quite understandable and newbe-friendly... thank you for making me read it...
Wait a moment... After learning about this some more I have to dig this up again: I had been under the impression, that Constructors always build Objects. But Structs never inherit from anything & also have Constructors = not all Objects can be instances of the class "Object"?? :-/
Yes, Bampf's answer http://answers.unity3d.com/questions/2077/does-a-constructor-always-build-an-object affirms my guesswork...
An object is an instance of a class. There is no need for its class to inherit from the "Object" class for its instances to be called objects. The fact that there is an general class called "Object" is what you might call a reification of the object concept in the API. But such reification is not needed for the concept itself to exist.
