Consider:
team1.ShowTeam();The ShowTeam method contains:
public void ShowTeam()
{
this.DisplayName();
}Then DisplayName contains:
public void DisplayName()
{
System.Console.WriteLine(this.name);
}Execution does not stay on one source line.
It moves through a sequence of method calls.
Start with:
team1.ShowTeam();The first receiver is:
Each new method call temporarily moves execution into another method.
When the called method finishes, execution returns to the statement after the call in the previous method.
Conceptually, while DisplayName() is running:
Inside ShowTeamName, this refers to player1.
Inside DisplayName, this refers to team1.
Tracing requires both:
A small trace can be organized as:
| Step | Current object | Current method | Next call |
|---|---|---|---|
| 1 | player1 | ShowTeamName() | team1.DisplayName() |
| 2 | team1 | DisplayName() | display statement |
| 3 | team1 | DisplayName() finishes | return to Player method |
| 4 | player1 | ShowTeamName() finishes | return to caller |
This helps prevent the common mistake of assuming this always refers to the same object through the entire call chain.
A conceptual sequence diagram may show:
The vertical order shows call order.
The horizontal direction shows which object receives each message.
Every method in the current examples is void.
Methods still finish and return execution to their caller.
They simply do not return a data value.
Methods that return values are taught later.
A weak trace might say:
That may be the visible result, but it hides how execution reached that result.
A stronger trace explains:
That explanation connects source structure to runtime flow.
At every method call, ask:
Those questions prepare you to use debugger stepping and the Call Stack in CO-037.