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 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 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.

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 :