Programming 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 and class methods belong to the class as a whole and are shared rather than copied into every instance.

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.
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.

One class-owned value, separate object state

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.

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.