0.2.5 Object Identity, Type, and Values

A Model Needs More Than a Display Name

In a computerized model, it is useful to know three different things about an object:

identity — which specific object this is;
type — what kind of thing the object is;
values — what information the object currently contains.

These ideas may look similar at first, but they answer different questions.

Identity Answers “Which One?”

Suppose the Wildcats have two players:

Jordan;
Casey.

Inside a model, we need a way to distinguish those specific objects.

We might identify them as:

player1
player2

Those are object identities used in the model.

The identity tells us which particular object we are talking about.

Even if two players happened to have the same name, they would still need to be represented as different objects if they are different people.

Type Answers “What Kind of Thing?”

Both player1 and player2 represent players.

Their type can therefore be described as:

Player

A compact object-model notation can combine identity and type:

player1 : Player

Read this as:

Another object might be:

team1 : Team

or:

match1 : Match

The words before and after the colon have different jobs.

Before the colon: the specific object's identity.

After the colon: the object's type.

Values Answer “What Is True About It Right Now?”

Now add selected field values.

For example:

player1 : Player

Field	Value
name	Jordan
jerseyNumber	7
position	Forward
isAvailable	true

The identity is player1.

The type is Player.

The fields are name, jerseyNumber, position, and isAvailable.

The values are "Jordan", 7, "Forward", and true.

This is a snapshot of one object at a particular point in time.

Two Objects Can Have the Same Type

Consider:

player1 : Player

name = Jordan
jerseyNumber = 7

player2 : Player

name = Casey
jerseyNumber = 1

The two objects have the same type:

Player

But they are different objects because they have different identities:

player1

and

player2

A type describes a category or blueprint-like kind of thing.

An object represents one specific instance of that type.

Similar Values Do Not Make Two Objects the Same Object

Imagine two objects:

player3 : Player

name = Alex
jerseyNumber = 10

player4 : Player

name = Alex
jerseyNumber = 10

Their displayed values happen to match.

That does not automatically mean they are the same object.

The model still identifies them separately as player3 and player4.

This distinction matters whenever a computerized system must track individual things independently.

Same values and same identity are not the same idea.

Values Can Change While Identity Remains

Suppose Jordan becomes unavailable.

Before:

player1 : Player

name = Jordan
jerseyNumber = 7
isAvailable = true

After:

player1 : Player

name = Jordan
jerseyNumber = 7
isAvailable = false

The identity remains:

player1

The type remains:

Player

One value changed.

The object represents the same player in a different state.

This is why object models are often described as snapshots. They can show what is true about specific objects at a particular moment.

UML Object Diagrams Use This Same Idea

A UML object diagram is a formal way to show specific object instances and selected information about them.

An object is commonly shown as a rectangle with a header containing its identity and type, followed by the field values that matter in the diagram.

Conceptually, one object could look like this:

player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
isAvailable = true

In formal UML presentation, the object header is visually distinguished according to UML notation. Later activities will show you how to read and create that notation in the diagramming tool.

For now, focus on the meaning:

player1 identifies the object;
Player identifies its type;
the rows below show selected field values.

Not Every Field Has to Appear

An object diagram is still a model.

It does not need to display every possible piece of information about the object.

If the purpose is to understand Saturday's lineup, the diagram might show:

player identity;
type;
position;
availability.

It might leave out information that does not contribute to that purpose.

Abstraction still applies.

UML gives the model a consistent notation, but UML does not remove the need to decide what information belongs in the model.

Several Objects Can Form One Snapshot

A small soccer snapshot might include:

player1 : Player
-------------------------
name = "Jordan"
isAvailable = true

player2 : Player
-------------------------
name = "Casey"
isAvailable = true

team1 : Team
-------------------------
name = "Wildcats"

match1 : Match
-------------------------
opponent = "Rangers"
location = "North Field"

Each box represents one specific object.

Together, the objects begin to describe the state of the soccer system.

One important piece is still missing: how those objects are connected.

That is the role of object relationships.

Keep These Three Questions in Mind

When you encounter an object in a model, ask:

Which specific object is this?

That is its identity.

What kind of object is it?

That is its type.

What information does it currently contain?

Those are its selected field values.

Those three ideas are the foundation for reading UML object diagrams.