What Is Class What Is Object - Learning Module

Loading content...

0/246

Class vs Object Relationship

The Fundamental Duality

We've established that classes are blueprints and objects are instances. But the relationship between them is richer than a simple template-to-product correspondence. Understanding this relationship deeply—how types work, how the runtime uses class information, and what this duality enables—is essential for advanced OOP reasoning.

This page explores the class-object relationship from multiple perspectives: the type system viewpoint, the memory model viewpoint, and the conceptual design viewpoint. By the end, you'll understand not just what classes and objects are, but how they work together to enable the powerful programming paradigm we call object-orientation.

What You Will Learn

By the end of this page, you will understand how classes define types, how objects relate to types at runtime, the distinction between static and dynamic types, and how this relationship forms the foundation for polymorphism and type-safe programming.

The Type System Perspective

In programming languages, a type is a classification that determines what values are valid and what operations are legal. When you define a class, you are creating a new type.

Classes as type definitions:

When you write class Dog { ... }, you are doing two things:

Defining the structure and behavior of Dog objects (the blueprint)
Creating a new type called Dog that can be used in variable declarations, method parameters, return types, and generics

This dual role—specification and type—is fundamental to understanding how OOP languages work.

Variables and types:

When you declare a variable with a class type:

Dog myDog;

You are saying:

myDog is a variable that can hold a reference to a Dog object
Any object assigned to myDog must be of type Dog (or a subtype of Dog)
The compiler will allow calls to methods defined in the Dog class

The type system enforces these rules at compile time, preventing many bugs before the program ever runs.

TypeSystem.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
public class Animal {
    public void breathe() {
        System.out.println("Breathing...");
    }
}
 
public class Dog extends Animal {
    public void bark() {
        System.out.println("Woof!");
    }
}
 
public class Cat extends Animal {
    public void meow() {
        System.out.println("Meow!");
    }
}
 
public class TypeDemo {
    public static void main(String[] args) {
        // Variable 'myDog' has STATIC TYPE 'Dog'
        // The object has DYNAMIC TYPE 'Dog' (same in this case)
        Dog myDog = new Dog();
        
        // The compiler knows myDog is a Dog, so this is allowed:
        myDog.bark();    // OK: Dog has bark()
        myDog.breathe(); // OK: Dog inherits breathe() from Animal
        
        // Variable 'animal' has STATIC TYPE 'Animal'
        // But the object still has DYNAMIC TYPE 'Dog'
        Animal animal = myDog;  // OK: Dog IS-A Animal
        
        animal.breathe(); // OK: Animal has breathe()
        // animal.bark();  // COMPILE ERROR: Animal type doesn't have bark()
        
        // Even though the actual object IS a Dog that CAN bark,
        // the compiler only knows it's an Animal
        
        // At runtime, we can check and cast:
        if (animal instanceof Dog) {
            Dog recoveredDog = (Dog) animal;
            recoveredDog.bark();  // OK: now compiler knows it's a Dog
        }
    }
}

Static vs Dynamic Typing

In statically typed languages (Java, C++, TypeScript), types are checked at compile time. In dynamically typed languages (Python, JavaScript, Ruby), types are checked at runtime. The class-object relationship exists in both, but is enforced differently.

Static Type vs Dynamic Type

One of the most important concepts in understanding the class-object relationship is the distinction between static type and dynamic type:

Static Type (Compile-Time Type):

The type declared in the source code for a variable
Known at compile time
Determines what operations the compiler allows
Doesn't change during program execution (the variable's type is fixed)

Dynamic Type (Runtime Type):

The actual class of the object at runtime
May be the declared type or any subtype
Known only at runtime
Determines which method implementation is called (method dispatch)

This distinction is the foundation of polymorphism.

Static Type vs Dynamic Type
Aspect	Static Type	Dynamic Type
When known	Compile time	Runtime
Where specified	Variable declaration	Object creation (new)
What it determines	Allowed operations	Method implementation used
Can change?	No (fixed at declaration)	No (fixed at creation)
Example	`Animal pet;`	`pet = new Dog();`
In example above	Static type is Animal	Dynamic type is Dog

Why this matters:

Consider the following code:

Animal pet = new Dog();
pet.makeSound();  // Which implementation runs?

Static type (Animal) tells the compiler that makeSound() is a valid call
Dynamic type (Dog) tells the runtime which makeSound() to execute

If both Animal and Dog have a makeSound() method, the Dog's version runs. This is called dynamic dispatch or virtual method invocation, and it's the mechanism behind runtime polymorphism.

DynamicDispatch.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public class Animal {
    public void makeSound() {
        System.out.println("Some generic sound");
    }
}
 
public class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}
 
public class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Meow!");
    }
}
 
public class DynamicDispatchDemo {
    public static void main(String[] args) {
        // Static type: Animal for all three
        // Dynamic types: Dog, Cat, Animal
        Animal[] pets = {
            new Dog(),    // dynamic type = Dog
            new Cat(),    // dynamic type = Cat
            new Animal()  // dynamic type = Animal
        };
        
        // Same static type, but different dynamic types
        // Results in different behaviors!
        for (Animal pet : pets) {
            // Compiler checks: "Does Animal have makeSound()?" Yes.
            // Runtime checks: "What's the actual class?" Calls that version.
            pet.makeSound();
        }
        // Output:
        // Woof!
        // Meow!
        // Some generic sound
    }
}

The Power of Dynamic Dispatch

Dynamic dispatch is what makes OOP so powerful. You can write code that works with a general type (Animal) but automatically uses the correct specific behavior (Dog's bark, Cat's meow) at runtime. This is the foundation of the Strategy pattern, Template Method pattern, and many other design patterns.

The Memory Model Perspective

Understanding how classes and objects actually exist in memory deepens your intuition about their relationship.

Classes in memory:

Class information (metadata) is typically stored in a special memory area (method area in JVM, equivalent spaces in other runtimes)
This includes: method bytecode/machine code, field definitions, type hierarchy information
This information is loaded once per class, regardless of how many objects are created

Objects in memory:

Objects are typically allocated on the heap
Each object contains: instance data (field values) + a pointer/reference to its class information
The pointer to class information is how the runtime knows the object's type and finds its methods

The critical insight:

An object knows what class it is. This pointer from object to class is what enables:

Runtime type checking (instanceof)
Dynamic method dispatch
Reflection and introspection

Visualizing the memory layout:

METHOD AREA (shared)              HEAP (per-object)
┌─────────────────────┐           ┌──────────────────────┐
│ Class: Dog          │◄──────────│ Dog Object #1        │
│ - method: bark()    │           │ - classPtr ──────────┼─┐
│ - method: eat()     │           │ - name: "Max"        │ │
│ - field: name       │           │ - age: 3             │ │
│ - parent: Animal    │◄──┐       └──────────────────────┘ │
└─────────────────────┘   │       ┌──────────────────────┐ │
                          │       │ Dog Object #2        │ │
┌─────────────────────┐   │       │ - classPtr ──────────┼─┘
│ Class: Animal       │◄──┘       │ - name: "Bella"      │
│ - method: breathe() │           │ - age: 5             │
└─────────────────────┘           └──────────────────────┘

One Dog class definition, shared by all Dog objects
Each Dog object has its own data (name, age) but points back to the shared class
Method code exists once; the this reference during invocation tells which object's data to use

Implications for Design

•Memory efficiency — Method code is shared, not duplicated. Creating 1 million Dog objects doesn't duplicate method code 1 million times.
•Consistent behavior — All instances of a class share the same method implementations, ensuring consistency.
•Runtime type knowledge — Each object carries its type, enabling runtime checks and dynamic dispatch.
•Inheritance chain — The class's parent pointer enables walking up the hierarchy for inherited methods.

Objects and References

In most OOP languages, variables don't hold objects directly—they hold references (or pointers) to objects. This distinction is crucial.

What this means:

Dog myDog = new Dog("Max");

myDog is a variable that holds a reference (an address in memory)
The actual Dog object lives on the heap
myDog points to that object

Consequences of reference semantics:

Assignment copies references, not objects:

Dog a = new Dog("Max");
Dog b = a;  // b now points to the SAME object as a

Comparison with == checks identity:

Dog a = new Dog("Max");
Dog b = new Dog("Max");
a == b  // false: different objects (even though same contents)

Method parameters receive references:

void rename(Dog dog) {
    dog.setName("Bella");  // modifies the ORIGINAL object
}

Null represents "no object":

Dog myDog = null;  // myDog doesn't reference any object

References.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public class Dog {
    private String name;
    
    public Dog(String name) { this.name = name; }
    public void setName(String name) { this.name = name; }
    public String getName() { return this.name; }
}
 
public class ReferenceDemo {
    public static void rename(Dog dog) {
        // 'dog' receives a COPY of the reference
        // But it points to the SAME object
        dog.setName("Bella");
    }
    
    public static void reassign(Dog dog) {
        // This only changes the local copy of the reference
        // The caller's reference is unaffected
        dog = new Dog("Other");
    }
    
    public static void main(String[] args) {
        Dog original = new Dog("Max");
        
        // Pass reference to rename()
        rename(original);
        System.out.println(original.getName()); // "Bella" - object WAS modified
        
        // Pass reference to reassign()
        reassign(original);
        System.out.println(original.getName()); // Still "Bella" - reference unchanged
        
        // Aliasing demonstration
        Dog alias = original;
        alias.setName("Rex");
        System.out.println(original.getName()); // "Rex" - same object!
    }
}

The Aliasing Trap

When multiple references point to the same object (aliasing), modifications through any reference affect the shared object. This is a major source of bugs. Defensive copying, immutable objects, and clear ownership semantics help mitigate aliasing issues.

The Conceptual Relationship

Beyond the technical mechanics, there's a powerful conceptual relationship between classes and objects that informs good design.

Classes represent categories; objects represent individuals:

The class Employee represents the category of all employees
An object john = new Employee("John", "Engineering") represents one specific employee

Classes define the essential nature; objects exhibit particular manifestations:

The class defines what it means to be an Employee (has name, department, salary; can work, take vacation)
Each object is an Employee with its own specific attributes

The philosophical parallel:

Aristotle distinguished between:

Form — The abstract essence or pattern of a thing
Matter — The physical substance that embodies the form

In OOP:

Class — The form (structure, behavior, identity)
Object — The matter (concrete existence, specific state)

A class is the form of all possible employees; each employee object is matter experiencing that form with particular values.

Classes Define

•What attributes entities have
•What behaviors entities support
•What invariants must hold
•What relationships are possible
•The type for static checking
•A template for instantiation

Objects Exhibit

•Specific attribute values
•Actual behavior execution
•Current state at any moment
•Actual relationships with other objects
•Runtime identity and lifecycle
•Participation in running systems

Design implications:

This conceptual relationship guides design decisions:

When modeling, ask: "What category does this represent?" — If you're designing a Customer class, think about the abstract category of customers, not any specific customer.
Keep classes focused on essence, not accidents. — A class should capture what's definitionally true of all instances, not coincidental details of particular ones.
Let objects vary in state, not in kind. — All objects of a class should follow the same behavioral contract. Variations should be in data (state), not in structure.
Use inheritance for true categorical relationships. — A Dog IS-A kind of Animal. This is a categorical relationship. Don't use inheritance just for code reuse.

How This Relationship Enables Polymorphism

The class-object relationship directly enables polymorphism—the ability to treat objects of different classes through a common interface. This is one of the most powerful features of OOP.

The mechanism:

Define a common interface (via base class or interface type)
Multiple classes implement/extend that interface
Client code uses the interface type (static type)
At runtime, the actual object (dynamic type) determines behavior

Example scenario:

A drawing application needs to render shapes. Without polymorphism, you'd need:

if (shape.type == CIRCLE) { drawCircle(shape); }
else if (shape.type == RECTANGLE) { drawRectangle(shape); }
else if (shape.type == TRIANGLE) { drawTriangle(shape); }
// Every new shape requires modifying this code!

With polymorphism:

for (Shape shape : shapes) {
    shape.draw();  // Each shape knows how to draw itself
}
// Adding new shapes requires NO changes here!

Polymorphism.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// Common interface (static type for client code)
public abstract class Shape {
    public abstract void draw();
    public abstract double area();
}
 
// Concrete implementations (possible dynamic types)
public class Circle extends Shape {
    private double radius;
    
    public Circle(double radius) { this.radius = radius; }
    
    @Override
    public void draw() {
        System.out.println("Drawing circle with radius " + radius);
    }
    
    @Override
    public double area() {
        return Math.PI * radius * radius;
    }
}
 
public class Rectangle extends Shape {
    private double width, height;
    
    public Rectangle(double w, double h) { width = w; height = h; }
    
    @Override
    public void draw() {
        System.out.println("Drawing rectangle " + width + "x" + height);
    }
    
    @Override
    public double area() {
        return width * height;
    }
}
 
// Client code works with abstract type
public class DrawingApp {
    public void renderAll(List<Shape> shapes) {
        for (Shape shape : shapes) {
            // Static type: Shape
            // Dynamic type: varies (Circle, Rectangle, etc.)
            shape.draw();  // Polymorphic dispatch!
        }
    }
    
    public double totalArea(List<Shape> shapes) {
        return shapes.stream()
                     .mapToDouble(Shape::area)
                     .sum();
    }
}

The Open-Closed Principle

Polymorphism enables the Open-Closed Principle: code is open for extension (add new Shape subclasses) but closed for modification (existing code using Shape doesn't change). This is foundational to maintainable, extensible software.

Summary: The Class-Object Relationship

We've explored the class-object relationship from multiple angles. Let's consolidate our understanding:

Key Takeaways

•Classes define types — Beyond being blueprints, classes create types that enable static type checking and define legal operations.
•Static type vs dynamic type — Variables have static types (compile-time); objects have dynamic types (runtime). This distinction enables polymorphism.
•Memory efficiency through sharing — Class definitions (methods, metadata) are shared; only instance data is per-object.
•References, not objects — Variables hold references to objects. Assignment copies references, creating aliases.
•Categories and individuals — Conceptually, classes represent categories of things; objects represent specific individuals.
•Polymorphism foundation — The static/dynamic type relationship enables treating diverse objects through common interfaces.

What's next:

Now that we understand the fundamental class-object relationship, the next page explores a powerful consequence: creating multiple objects from the same class. We'll see how this enables collections, concurrent processing, and real-world system modeling.

Deep Understanding Achieved

You now understand the class-object relationship at multiple levels: types, memory, references, and concepts. This understanding is essential for advanced topics like design patterns, SOLID principles, and architectural decisions.