Code Companion
Java

Programming technique · B3.1.3

Static and instance members

Class and instance members

Instance members belong to one object. Static members belong to the class as a whole and are shared rather than copied into every instance.

Instance attributes belong to one object. Class attributes belong to the class as a whole and are shared. Instance methods, class methods and static methods differ by what context they receive.

IB DP CS standard B3.1.3: Distinguish between static and non-static variables and methods, including ownership, usage, scope and when instance state is more appropriate.

What you need to be able to do

Identify ownership

Decide whether a value belongs to one object or to the class as a whole.

Choose the right method type

Use instance behaviour when one object's state matters, and class-owned behaviour only when the responsibility genuinely belongs to the class.

Explain consequences

Predict what happens when state is accidentally shared or a method has the wrong ownership.

Two meanings of static: a static data structure has a fixed size. A static Java class member—or class-owned Python attribute—is shared by a class. These are different ideas.

Start with one question: who owns this?

Look at this deliberately flawed GamePlayer design. Imagine creating Ana and Luis as two players.

If health and score describe each individual player, storing them at class level makes the design say something different: there is one shared health and one shared score for every player.

Diagnose the ownership bug

Answer each question before opening the model answer.

  1. Should username belong to each GamePlayer object or to the GamePlayer class?

    Reveal model answer

    Each object. Ana and Luis need different usernames, so username is instance state.

  2. If every player needs independent health, what is wrong with storing health at class level/static level?

    Reveal model answer

    There would be one shared health value rather than one value per player. Damage intended for one player could affect the shared state.

  3. If takeDamage/take_damage changes one player’s health, should it be an instance method or a class-owned method?

    Reveal model answer

    An instance method, because it needs a particular receiving player and that player’s health.

One class-owned value, separate object state

A shared member can still be useful when the responsibility is genuinely class-wide. Here every object gets independent identity/state, while the class tracks how many objects have been created.

RegistryUnit class

Shared once: createdCountcreated_count

0 → 1 → 2

Each object

first

id
1
name
Ari
energy
8

second

id
2
name
Sol
energy
12
RegistryUnit
+ createdCount: int {static}+ id: int+ name: String+ energy: int
+ RegistryUnit(name, energy)+ summary(): String+ getCreatedCount(): int {static}
RegistryUnit
+ created_count: int {class}+ id: int+ name: str+ energy: int
+ __init__(name, energy)+ summary(): str+ get_created_count(): int {class}

Java ownership model

Python ownership model

Distinguish members by responsibility

QuestionInstance memberClass-owned member
OwnerOne objectThe class as a whole
Stored valuesNormally one per objectOne shared value
Typical accessfirst.summary()RegistryUnit.getCreatedCount()RegistryUnit.get_created_count()
Suitable useIdentity or state that differs between objectsA genuine responsibility shared by the class
Ask who owns the value or behaviour. Do not make data class-owned merely to make it easier to access.

Class-owned does not mean constant

The shared count changes while remaining owned by the class.

Objects keep independent state

Ari and Sol must not share one name or energy value.

Use the class name

Shared state is clearest when accessed through RegistryUnit, not an arbitrary object.

Methods follow the same ownership decision

Method kindUse it when...Java formPython form
Instance methodThe operation needs one object's state or identity.ordinary non-static method; can use thisordinary method; receives self
Class-owned methodThe operation belongs to the class rather than one instance.static method@classmethod when class context/state is needed
Utility methodThe logic is related to the class but needs neither object state nor class state.often static@staticmethod

Python distinction: @classmethod receives the class as cls; @staticmethod receives neither self nor cls. They are not identical features, but both help separate class-related behaviour from behaviour that needs one object.

Java distinction: a static method has no receiving object and therefore cannot directly use instance fields through this.

Choose the member type

Decide ownership first; syntax comes second.

  1. LibraryBook title: instance or class-owned?

    Reveal model answer

    Instance. Different book objects need different titles.

  2. LibraryBook library_name, if every book belongs to the same one library in this program: could it be class-owned?

    Reveal model answer

    Possibly. If it is genuinely shared by every LibraryBook object and belongs to the class-wide model, class-owned state is defensible.

  3. A created-count shared by every object: instance or class-owned?

    Reveal model answer

    Class-owned, because there should be one count for the class rather than a separate unrelated count in every object.

  4. A method that reduces one player’s health: instance or static/class-owned?

    Reveal model answer

    Instance, because it must act on a particular player’s state.

  5. A username-format checker that needs no player data: could it be static?

    Reveal model answer

    Yes. It is related utility logic but does not need one receiving object. In Python, @staticmethod is suitable for that pattern.

Apply ownership deliberately

In the challenge, justify every shared member. If you cannot explain why there should be exactly one class-owned value or behaviour, it probably belongs to the objects instead.

Challenges Choose one

Choose a challenge that feels appropriate for you. Code heat is only a rough estimate, not a fixed level.

Registry Unit Counter

Challenge ID: PC-T20-C01 · Standards: B3.1.3

Complete a RegistryUnit class with one class-owned created count and independent id, name and energy fields for every object. The constructor must update the shared count and assign the new value as the object's id. Create at least three objects, trace the count after each construction and distinguish the receiver-based summary method from the class-owned count reader.

Scaffold available
Several RegistryUnit objects with independent identifiers and one shared class-owned object counter.

Dice Roll Statistics

Challenge ID: PC-T20-C02 · Standards: B3.1.3, B3.1.4

Create a Dice class in which each object stores its own number of sides and current value, while one static totalRolls field counts rolls made by every Dice object. Roll dice of different sizes, display their independent values and prove that the shared total belongs to the class rather than one die.

Scaffold available
Several Dice objects with individual current values and shared class-level roll statistics.

Club Membership Counter

Challenge ID: PC-T20-C03 · Standards: B3.1.3, B3.1.4

Create a ClubMember class with independent memberId, name and yearGroup fields and one class-owned memberCount. Give each new object the next id during construction. Add an instance summary method and a static count reader, then explain why names and year groups must not be static.

Scaffold available
Individual ClubMember objects with their own details and one shared class-owned member count.