1.1.5 Instantiating Objects

• 1.2g Object Instantiation and Assignment (21.12)

A Class Describes a Type; an Object Is a Specific Instance

You have already seen object types such as:

Player
Team
Match

A type describes what kind of object can exist.

A running program needs a specific object instance before it can work with that object's state.

Creating an object instance is called instantiation.

In C#, the new operator creates the instance.

Read a Basic Instantiation Statement

Consider:

Player player1 = new Player();

Break the statement into parts.

Player

This is the type.

player1

This is the variable/reference name the code will use for the object.

new Player()

This creates a new Player object.

Read the whole statement as:

Create a new Player object and let player1 refer to it.

Each new Creates a Distinct Object

Consider:

Player player1 = new Player();
Player player2 = new Player();

The program executes two new Player() expressions.

That creates two separate Player objects.

They have the same type.

They do not have the same identity.

This connects directly to UML object diagrams:

player1 : Player
player2 : Player

Two object boxes of the same type can still represent two different instances.

The Variable Is Not the Object Itself

At an introductory level, it is tempting to say:

player1 is the object.

A more precise mental model is:

player1 is the name the code uses to refer to the Player object created by new.

That distinction becomes increasingly useful as you begin connecting objects to one another.

For now, keep the idea simple:

player1 → one Player object

Use Types That Already Exist in the Supplied Project

In Module 1.1, you are working with supplied classes.

If the project provides a type named:

Player

you can instantiate that type.

Do not invent new class definitions merely because you want another object.

Defining classes in C# is taught later.

The current task is creating instances of existing types.

Instantiation Happens Before the Object Can Hold Scenario State

A typical sequence is:

Player player1 = new Player();

Then later statements can establish the state required by the current task.

Conceptually:

create object
    ↓
assign its required field values
    ↓
connect it to other objects when required

Instantiation is the first step.

It does not automatically fill every field with the intended scenario values.

New Objects Begin With Their Current Default State

Immediately after:

Player player1 = new Player();

the object exists.

Its fields have their current initial/default values unless the supplied class establishes other initialization behavior.

The course looks more closely at default field values in the next batch.

For now, understand that:

creating the object and assigning the intended scenario values are separate ideas.

Connect Instantiation to the UML Model

Suppose a UML object diagram shows:

player1 : Player

A matching C# instantiation can begin with:

Player player1 = new Player();

The UML says:

A particular Player instance named player1 exists in this snapshot.

The C# says:

Create a Player object and keep a reference to it using player1.

The representations are different.

The object concept is connected.

Do Not Create Extra Objects Without a Modeling Reason

If the UML shows one Player instance, do not create three Players just because object creation is easy.

The code should reflect the intended model.

For every new expression, ask:

Which object in the requirement or UML is this creating?

That question keeps instantiation tied to the design rather than becoming random code.