The Difference Between Classes, Objects, and Instances

The difference between Classes, Objects, and Instances

Java (and any other programming language) is modeled in terms of types and values. At the theoretical level, a value is a representation for some quantum of information, and a type is a set of values. When we say value X is an instance of type Y, we are simply saying that X is a member of the set of values that is the type Y.

So that's what the term "instance" really means: it describes a relationship not a thing.

The type system of the Java programming language supports two kinds of types, primitive types and reference types. The reference types are further divided into the classes and array types. A Java object is an instance of a reference type.

An object is a class instance or an array. (JLS 4.3.1)

That's the type theoretic view.

In practice, most Java developers treat the words "instance" and "object" as synonyms. (And that includes me then I'm trying to explain something quickly.) And most developers use the word "value" rather than "instance" to refer to an instance of a primitive type.

Difference between object and instance

A blueprint for a house design is like a class description. All the houses built from that blueprint are objects of that class. A given house is an instance.

Difference between Object and instance : C++

In C++ "object" and "instance" are used nearly interchangably.

There is a general programming design pattern of class and instance. The class holds the information about all instances in that class.

In C++ when you declare a class or struct, the compiler makes code that describes how you create an instance of that class, what the data layout is, and provides some methods that can be used to interact with that instance (up to and including destruction).

virtual methods and inheritance seemingly moves some of the methods and layout to the instance: but the amount is quite limited. Instead, each instance holds pointers to virtual class data. In some languages, you can do things like replace individual methods of an instance at runtime: but not in C++.

When you create an instance of that class or struct, it can be via an automatic named variable on the stack (like Foo f;), an anonymous automatic named variable (like some_function( Foo(17,22) )), an instance on the free store (like new Foo(17, 22)), or via placement-new (which is how std::vector and std::make_shared creates instances).

Confusingly, there is a separate parallel class-instance pattern in C++ -- class template-class. The class template is the class, the instantiation is the instance. The template arguments and specializations indicate how, at compile time, you can "construct" the classes. Pattern matching on the class templates provide a limited amount of properties that are not tied to the instances ("class properties" in the pattern). (Arguably the function template-function is another instance of the pattern).

If you look at the C++1y proposal for concepts lite you will see where object and instance might mean different things in C++.

int x = 0;
int& foo = x;
int* bar = &x;

x is both an object and an instance of the type int.

foo is an instance of the type int&, but calling foo an object is probably wrong! It is a reference -- an alias, or a different name for some object (in this case x).

bar is a pointer to an int, which is an instance of type int*, and calling it an object is probably correct.

This is a useful distinction: a type does not have to denote an object type if it is a reference type. Object types behave differently than reference types in a number of important ways.

Now, some types have "reference semantics", in that they behave like references in many ways, but are actually classes. Are instances of such a type better called references or objects? In horrible cases, some instances have a mixture of both reference and object semantics: such is often a bad sign.

Via latest standard in 3.9 [Types] we have the kinds of types in C++. They describe what an object type is:

Types describe objects (1.8), references (8.3.2), or functions (8.3.5)

and

An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not a void type.

So calling the "instances" of things that are function types or reference types "objects" seems incorrect. Note that accessing the "representation" of a function or a reference instance is basically impossible: references alias into the object they refer to, and using the name of a function decays to a pointers-to-functions at the drop of a hat (and pointers-to-a-function are basically opaque handles that let you invoke them).

So arguably functions are not instances, and references are not instances.

On the third hand, we do talk about instantiations of class templates and function templates. 14.7 is "template instantiation and specialization", and points of instantiation (of a template) are all formal terms from the standard.

What is the difference between a namespace, a class, an object and an instance?

I would say:

• Namespace: A category or brand of cars. Note that the brand really doesn't have to dictate how the car is built. You can't say a Honda always have four doors, or that it always has 4wd. Such specifics is up to the class to dictate. Rich.Carpenter's post explains the purpose of namespaces very well.

• Class: Blueprint for how to build a specific car.

• Object: An actual car (instance) created from the car blueprint (the class)

• Method: Something a user of the car can make it do. Start(), IncreaseThrottle(), Brake(), OpenDoor(), etc.

• Property: Attributes, information and building blocks which the car contains. E.g. Total running miles, color, steering wheel dimension, stereo system etc etc.

Some concepts which could seem more advanced to you. Maybe overkill right now, but read it if you're interested:

• Inheritance: When a class is based on another class and adds some more specific details. A line of inheritance usually goes from the most common and general aspect, all the way down to a point where it makes no more sense to be more specific. Example of this in the context of animals: Animal->Mamal->Rodent->Rat->RattusNorvegicus

• Aggregates: Properties that "builds" the object. E.g. "This car is an aggregation of four wheels, a chassis, an engine, etc".

• Attribute: Properties that describe the object, usually not part of its physical construction. E.g. Color, top speed, engine volume etc.

• Encapsulation: The concept of concealing certain properties from the user, or to protect certain properties from being used incorrectly (and thereby damaging the object). E.g. You don't expose the gear-property of a car class to be altered freely. You encapsulate it and make sure Clutch() is called before SetGear().

• Overriding: If a class inherits from another class, it also inherits methods from that class. Overriding is basically when the inheriting class replaces the implementation of such a method with its own required behaviour. Example of usage in next point.

• Polymorphism: A difficult concept to grasp until you start using it practically. It means referring to a very specific kind of object, by using a generic reference which allows you to ignore the specific type (when you don't need to know it). E.g. If you want to "read" the license plate number property of every vehicle in a parking lot, you don't really care what the brand is, or even if it's a trailer or motorcycle or whatever. To be able to do this, we make sure the license plate number is a property in the most general class in the inheritance line (probably the Vehicle class). So you only have to deal with all the objects in a list by referring to them as their Vehicle class and then calling Vehicle::GetLicensePlateNumber(). Any vehicle requiring some special handling to retrieve the number can implement this behaviour by overriding the method and make it behave as required. So, a wide range of object types can be used as if they were of the same type, but can behave differently.

---

Related Topics