A class groups information that belongs to one concept.
Encapsulation is the idea that a class should control how its internal state is exposed and changed.
At this stage, the goal is conceptual.
You are beginning to ask:
Which parts of this object should other code be allowed to access directly?
If a field is directly accessible, other code can change it.
Conceptually:
player1.jerseyNumber = 7;
Direct access can be useful while learning object fundamentals.
As applications grow, unrestricted access can make it harder to protect valid state.
A class can mark some information as private.
That means unrelated outside code cannot directly reach that member in the same way.
This can help keep responsibility inside the class.
The detailed use of public and private modifiers appears later in this module.
For now, focus on the reason:
an object should not expose more of its internal state than the program needs.
Imagine a soccer Player object.
If every other class can freely change every field, it becomes difficult to know which code is responsible for the Player's state.
Encapsulation helps create clearer boundaries:
Player object
owns Player state
Other parts of the program should interact through the access the class intentionally provides.
A useful class still needs to cooperate with the rest of the application.
The goal is controlled access, not complete isolation.
Later modules introduce methods, constructors, and properties that provide stronger ways to manage object state.
Class diagrams can eventually indicate whether members are public or private.
You will first learn the basic class-and-field notation before adding more detail.
Encapsulation asks:
Which class owns this state, and how much direct access should other code have?
That question becomes increasingly important as classes become more capable.