1.4.11 Variables vs Fields

Fields and Variables Both Hold Values, but They Serve Different Roles

C# uses named storage in several contexts.

Two important categories are:

fields
variables used within method execution

They can both hold values.

They do not represent the same kind of program state.

A Field Belongs to an Object or Class

Consider:

class Player
{
    public int jerseyNumber;
}

The field jerseyNumber is part of the Player object's structure.

After:

Player player1 = new Player();

that Player object has its own jerseyNumber field.

Another Player object has its own field:

Player player2 = new Player();

Conceptually:

Activity diagram showing player1 jerseyNumber, then player2 jerseyNumber. — Player1JerseyNumber.

The field is part of each object's state.

A Parameter Is a Variable Used by a Method Call

Consider:

public void SetJerseyNumber(int number)
{
    this.jerseyNumber = number;
}

The parameter number is a variable available during that method call.

It receives the caller's argument.

It is not a permanent field on the Player object.

Compare the Two Names in One Assignment

This line:

this.jerseyNumber = number;

contains both ideas.

Field

this.jerseyNumber

belongs to the current Player object.

Parameter variable

number

belongs to the current method call.

The assignment copies the incoming value into the object's state.

Field State Can Remain After the Method Finishes

Suppose:

player1.SetJerseyNumber(7);

During the call:

number = 7

The method assigns:

this.jerseyNumber = number;

After the method finishes, the parameter number is no longer available as that active method parameter.

But the Player field can still contain:

jerseyNumber = 7

The field is part of the object's continuing state.

Local Variables Also Belong to Method Execution

C# methods can declare local variables.

A local variable belongs to the method or block scope where it is declared.

Later Learning Activities show how to declare, initialize, and use local variables in calculations and decisions.

For this page, the key distinction is:

Field

Parameters are one kind of method-level variable.

Do Not Turn Every Temporary Value into a Field

Suppose a method needs a value only while performing one task.

That value does not automatically need to become permanent object state.

Fields should represent information the object needs to keep as part of its design.

Method-level variables support the method's current work.

Do Not Use a Temporary Variable When the Requirement Is Object State

If the Player is required to remember its jersey number after SetJerseyNumber finishes, storing the value only in the parameter is not enough.

The method needs to transfer that value into the field:

this.jerseyNumber = number;

Scope Helps You Tell Them Apart

When reading unfamiliar source, ask:

Was the name declared in the class body?

It may be a field.

Was the name declared in a method parameter list?

It is a parameter.

Was the name declared inside a method body?

It is a local variable.

The declaration location helps reveal the role and scope.

The Debugger Shows Both Kinds of Information

While paused inside a method, debugger windows can show:

the current object and its fields;
the current parameter values;
later, local variables.

That lets you distinguish:

object state

from:

method execution state

The Module 1.4 Foundation

CO-038 establishes this information flow:

Object diagram showing caller supplies argument, then parameter receives value, then method uses scoped variable, then method may assign value to a field, then object state changes. — CallerSuppliesArgument.

Later Module 1.4 activities add UML parameter notation, comparisons, null checks, multiple parameters, local variables, and more complex conditional logic.