Instance Members — Per-Object State and Behavior - Static vs Instance Members | OneNoughtOne

0/290

Low-Level DesignStatic vs Instance Members

Static vs Instance Members

LevelBeginner

Duration50 mins

TopicStatic vs Instance Members

1 / 4

Instance Members — Per-Object State and Behavior

The Object's Personal Space

Imagine a world where every person shares the same bank account balance. The moment anyone deposits or withdraws money, everyone's balance changes. Chaotic, right? Yet this is precisely what happens when developers misunderstand the difference between instance members and static members in object-oriented programming.

In well-designed software, each object maintains its own private realm of data—its instance members. These are the attributes and behaviors that belong to this specific object and no other. When you create a BankAccount object for Alice and another for Bob, each maintains its own balance, transaction history, and account number. This is the essence of instance members: per-object state and behavior.

What You Will Learn

By the end of this page, you will understand exactly what instance members are, how they're stored in memory, why they're fundamental to object-oriented design, and how to reason about per-object state in complex systems. You'll gain the mental model that distinguishes professional OO designers from developers who merely write classes.

Defining Instance Members

An instance member is any field or method that belongs to a specific instance of a class—an individual object created from that class's blueprint. When you write a class, you're defining the template. When you instantiate it, you're creating a concrete object with its own copy of instance data.

Let's establish precise definitions:

Instance Member Definitions

•Instance Field (Instance Variable): A variable declared inside a class but outside any method, without the static modifier. Each object gets its own independent copy of this variable.
•Instance Method: A method declared without the static modifier. It operates on a specific object's instance fields and can access this (or self in Python) to reference the current object.
•Instance Context: The runtime environment in which an instance method executes, providing access to the specific object's state through implicit or explicit reference.

The critical insight is independence. If you create 1,000 User objects, you have 1,000 separate copies of the username field, 1,000 separate copies of the email field, and so on. Changing one user's email has absolutely no effect on any other user's email. This isolation is what makes object-oriented programming tractable for modeling complex real-world domains.

instance_members_example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class BankAccount {
    // Instance fields - each object has its own copy
    private String accountNumber;      // Unique to this account
    private String ownerName;          // Unique to this account
    private double balance;            // Unique to this account
    private List<Transaction> history; // Unique to this account
    
    // Instance method - operates on THIS object's data
    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        this.balance += amount;  // Modifies THIS object's balance
        this.history.add(new Transaction("DEPOSIT", amount));
    }
    
    // Instance method - reads THIS object's data
    public double getBalance() {
        return this.balance;  // Returns THIS object's balance
    }
}
 
// Usage demonstrating independence
BankAccount aliceAccount = new BankAccount("ACC-001", "Alice", 1000.0);
BankAccount bobAccount = new BankAccount("ACC-002", "Bob", 500.0);
 
aliceAccount.deposit(200.0);  // Only affects aliceAccount
System.out.println(aliceAccount.getBalance());  // 1200.0
System.out.println(bobAccount.getBalance());    // 500.0 (unchanged)

The 'this' Reference Explained

When an instance method executes, the runtime implicitly passes a reference to the object on which the method was called. In Java and TypeScript, this is this; in Python, it's self. This reference is how the method knows which object's balance to modify. Without this mechanism, instance methods couldn't distinguish between Alice's account and Bob's account.

Memory Model — How Instance Members Are Stored

To truly understand instance members, you need to visualize what happens in memory when objects are created. This mental model is essential for reasoning about performance, debugging reference issues, and understanding why certain design patterns work the way they do.

The Heap and Object Allocation:

In most object-oriented languages, objects live in a region of memory called the heap. When you write new BankAccount(...), the runtime:

Calculates how much memory is needed for all instance fields
Allocates a contiguous block of memory on the heap
Initializes each instance field within that block
Returns a reference (pointer) to the start of that memory block

This reference is what gets stored in your variable. The variable itself doesn't contain the object—it contains the address of the object.

Converting Mermaid diagram...

Key Memory Insights:

•Complete Isolation: Each object occupies its own memory region. Modifying aliceAccount.balance writes to memory address ~0x1000, while bobAccount.balance is at ~0x2000. They cannot accidentally interfere.
•Memory Overhead: Creating N objects means allocating memory for N copies of all instance fields. 1 million User objects with 10 fields each = 10 million field allocations. This is why understanding instance vs static matters for memory-sensitive applications.
•Reference Semantics: Variables hold references, not objects themselves. When you pass aliceAccount to a method, you're passing a copy of the reference (the address), not a copy of the object. The method can modify the original object through that reference.
•Garbage Collection: When no references point to an object, it becomes eligible for garbage collection. The heap memory is reclaimed automatically in managed languages.

The Aliasing Trap

Because variables hold references, multiple variables can point to the same object: BankAccount shared = aliceAccount; Now both aliceAccount and shared reference the same object at 0x1000. Calling shared.deposit(100) affects what aliceAccount.getBalance() returns. This aliasing is a powerful feature but a common source of bugs when misunderstood.

Instance Fields — Encapsulating Object State

Instance fields are the persistent memory of an object. They store the data that defines what makes this particular object unique and maintain that data across method calls throughout the object's lifetime.

What Belongs in Instance Fields?

Not every piece of data should be an instance field. The guiding principle is: store data that characterizes the object's identity or state over time.

Instance Field Decision Guide
Data Characteristic	Should Be Instance Field?	Example
Unique to each object	✓ Yes	User's email address, order ID
Persists across method calls	✓ Yes	Account balance, connection status
Part of object's identity	✓ Yes	Employee ID, product SKU
Changes over object's lifetime	✓ Yes	Order status, game score
Same for all instances	✗ Use static	Tax rate, company name
Temporary computation result	✗ Use local variable	Loop counter, intermediate sum
Derived from other fields	✗ Consider computing on demand	Full name from first + last

Instance Field Categories:

Well-designed classes typically have instance fields that fall into distinct categories:

Categories of Instance Fields

•Identity Fields: Immutable data that uniquely identifies the object. Examples: userId, orderId, isbn. These are typically set once at construction and never changed.
•State Fields: Mutable data representing the object's current condition. Examples: orderStatus, connectionState, balance. These change as operations are performed.
•Configuration Fields: Settings that modify behavior but aren't core identity. Examples: maxRetries, timeout, locale. Often set at construction or through configuration methods.
•Relationship Fields: References to other objects this object is connected to. Examples: owner, parentNode, items. These encode the object graph structure.
•Cache Fields: Derived values stored for performance. Examples: cachedHashCode, fullNameCache. Must be invalidated when source data changes.

instance_field_categories
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
public class Order {
    // Identity fields - immutable, set once
    private final String orderId;
    private final Instant createdAt;
    private final Customer customer;  // Relationship field
    
    // State fields - change over time
    private OrderStatus status;
    private Instant lastUpdatedAt;
    
    // Relationship fields - connections to other objects
    private List<OrderItem> items;
    private Address shippingAddress;
    private PaymentMethod paymentMethod;
    
    // Configuration fields - behavior modifiers
    private boolean expressShipping;
    private String specialInstructions;
    
    // Cache fields - derived values for performance
    private BigDecimal cachedTotalAmount;
    private boolean totalAmountCacheValid;
    
    public Order(String orderId, Customer customer) {
        // Identity fields set at construction
        this.orderId = orderId;
        this.createdAt = Instant.now();
        this.customer = customer;
        
        // State initialized to starting values
        this.status = OrderStatus.PENDING;
        this.lastUpdatedAt = this.createdAt;
        
        // Relationships start empty
        this.items = new ArrayList<>();
        
        // Cache starts invalid
        this.totalAmountCacheValid = false;
    }
    
    public void addItem(OrderItem item) {
        this.items.add(item);
        this.lastUpdatedAt = Instant.now();
        this.totalAmountCacheValid = false;  // Invalidate cache
    }
    
    public BigDecimal getTotalAmount() {
        if (!totalAmountCacheValid) {
            // Recompute and cache
            cachedTotalAmount = items.stream()
                .map(OrderItem::getSubtotal)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
            totalAmountCacheValid = true;
        }
        return cachedTotalAmount;
    }
}

The Principle of Minimal State

Don't store what you can compute. If fullName is always firstName + ' ' + lastName, consider a method getFullName() rather than a field. Every instance field increases memory usage, creates synchronization concerns in concurrent code, and requires maintenance when related fields change. Store only what you must.

Instance Methods — Operating on Object State

Instance methods are the behaviors that objects can perform. They have a superpower that static methods lack: they can read and modify the instance fields of the specific object on which they're invoked.

The Implicit this Parameter:

When you call aliceAccount.deposit(100), something invisible happens. The runtime effectively translates this to deposit(aliceAccount, 100)—passing a reference to aliceAccount as a hidden first parameter. Inside the method, this reference is accessible as this (or self in Python).

This mechanism is how the same deposit method code can work on any BankAccount object while affecting only the specific object it's called on.

instance_method_mechanics
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public class Counter {
    private int count;  // Instance field
    
    // Instance method - has access to 'this'
    public void increment() {
        this.count++;  // 'this' refers to the object the method was called on
    }
    
    // Instance method - 'this' is implicit if unambiguous
    public int getCount() {
        return count;  // Equivalent to 'return this.count;'
    }
    
    // Instance method - 'this' is necessary when parameter shadows field
    public void setCount(int count) {
        this.count = count;  // 'this.count' is the field, 'count' is the parameter
    }
    
    // Instance method can call other instance methods on same object
    public void incrementBy(int amount) {
        for (int i = 0; i < amount; i++) {
            this.increment();  // Calls increment() on this same object
        }
    }
}
 
// Demonstrating 'this' in action
Counter c1 = new Counter();
Counter c2 = new Counter();
 
c1.increment();  // 'this' inside increment() refers to c1
c1.increment();  // 'this' inside increment() refers to c1
c2.increment();  // 'this' inside increment() refers to c2
 
System.out.println(c1.getCount());  // 2 - c1's count
System.out.println(c2.getCount());  // 1 - c2's count

Categories of Instance Methods:

Instance methods typically fall into recognizable patterns based on their relationship to object state:

•Accessors (Getters): Read instance state without modifying it. Return field values or computed properties. Examples: getBalance(), getName(), isActive().
•Mutators (Setters/Commands): Modify instance state. Change field values, often with validation. Examples: deposit(amount), setStatus(status), addItem(item).
•Query Methods: Compute and return information based on state without modifying it. Examples: calculateInterest(), isOverdue(), getTotalItems().
•Factory Methods (on instances): Create and return new objects, often based on current state. Examples: copy(), withUpdatedAddress(newAddress), split().
•Lifecycle Methods: Handle object creation, initialization, cleanup. Examples: init(), dispose(), close().

Command-Query Separation (CQS)

A valuable design principle: methods should either change state (commands) or return information (queries), but not both. A deposit() method should modify balance and return void, not return the new balance. If you need the new balance, call getBalance() afterward. This separation makes code easier to reason about and test.

Object State Transitions

One of the most powerful aspects of instance members is the ability to model stateful entities—objects that change over time in response to events. Understanding how to design and reason about state transitions is central to effective object-oriented programming.

The State Machine Perspective:

Every object with mutable instance fields can be viewed as a state machine. The fields define the current state, and the instance methods define the transitions between states. Well-designed objects make invalid state transitions impossible.

state_transitions_example
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
public class Order {
    public enum Status {
        PENDING,      // Initial state
        CONFIRMED,    // Payment received
        PROCESSING,   // Being prepared
        SHIPPED,      // In transit
        DELIVERED,    // Received by customer
        CANCELLED     // Terminal state (failure)
    }
    
    private Status status;
    private final List<String> statusHistory;
    
    public Order() {
        this.status = Status.PENDING;
        this.statusHistory = new ArrayList<>();
        this.statusHistory.add("Created with status: PENDING");
    }
    
    // State transition: PENDING → CONFIRMED
    public void confirm() {
        if (status != Status.PENDING) {
            throw new IllegalStateException(
                "Can only confirm PENDING orders, current: " + status);
        }
        this.status = Status.CONFIRMED;
        this.statusHistory.add("Confirmed at: " + Instant.now());
    }
    
    // State transition: CONFIRMED → PROCESSING
    public void startProcessing() {
        if (status != Status.CONFIRMED) {
            throw new IllegalStateException(
                "Can only process CONFIRMED orders, current: " + status);
        }
        this.status = Status.PROCESSING;
        this.statusHistory.add("Processing started at: " + Instant.now());
    }
    
    // State transition: PROCESSING → SHIPPED
    public void ship(String trackingNumber) {
        if (status != Status.PROCESSING) {
            throw new IllegalStateException(
                "Can only ship PROCESSING orders, current: " + status);
        }
        this.status = Status.SHIPPED;
        this.statusHistory.add("Shipped with tracking: " + trackingNumber);
    }
    
    // State transition: PENDING|CONFIRMED → CANCELLED
    public void cancel(String reason) {
        if (status != Status.PENDING && status != Status.CONFIRMED) {
            throw new IllegalStateException(
                "Cannot cancel order in status: " + status);
        }
        this.status = Status.CANCELLED;
        this.statusHistory.add("Cancelled: " + reason);
    }
    
    // Query methods for state
    public boolean canBeCancelled() {
        return status == Status.PENDING || status == Status.CONFIRMED;
    }
    
    public boolean isTerminal() {
        return status == Status.DELIVERED || status == Status.CANCELLED;
    }
}

Converting Mermaid diagram...

Enforcing Valid Transitions:

The power of this approach is that invalid transitions throw exceptions. You cannot ship a cancelled order. You cannot confirm an already-delivered order. The object protects its own consistency.

This is why instance methods are so valuable: they encapsulate the rules about what operations are valid given the current state. External code cannot directly modify the status field to an invalid value—it must go through methods that enforce the constraints.

State Explosion

Complex objects with many interdependent fields can suffer from 'state explosion'—so many possible combinations of values that reasoning about correctness becomes intractable. Mitigation strategies include: making fields immutable where possible, using enums for discrete states, grouping related fields into sub-objects, and leveraging the type system to make invalid states unrepresentable.

Object Identity and Equality

Instance members raise a fundamental question: when are two objects 'the same'? This seemingly simple question has two very different answers:

Identity vs Equality:

Identity (Reference Equality)

•Same memory location
•Exactly the same object instance
•Java: a == b
•Python: a is b
•Always fast: O(1) pointer comparison

Equality (Value Equality)

•Same meaningful content
•Logically equivalent objects
•Java: a.equals(b)
•Python: a == b
•Speed depends on implementation

identity_vs_equality
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public class Money {
    private final int cents;
    private final String currency;
    
    public Money(int cents, String currency) {
        this.cents = cents;
        this.currency = currency;
    }
    
    // Override equals for value equality
    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;  // Same identity → equal
        if (obj == null || getClass() != obj.getClass()) return false;
        Money other = (Money) obj;
        return cents == other.cents && 
               Objects.equals(currency, other.currency);
    }
    
    // Must override hashCode when overriding equals
    @Override
    public int hashCode() {
        return Objects.hash(cents, currency);
    }
}
 
// Demonstration
Money m1 = new Money(1000, "USD");
Money m2 = new Money(1000, "USD");
Money m3 = m1;  // m3 references same object as m1
 
// Identity checks
System.out.println(m1 == m2);  // false - different objects in memory
System.out.println(m1 == m3);  // true - same object
 
// Equality checks
System.out.println(m1.equals(m2));  // true - same value
System.out.println(m1.equals(m3));  // true - same value (and identity)

The HashCode Contract:

In Java and similar languages, equals and hashCode are tightly coupled. The contract states:

If a.equals(b) is true, then a.hashCode() == b.hashCode() must be true
If a.hashCode() != b.hashCode(), then a.equals(b) must be false

This contract is essential for hash-based collections like HashMap and HashSet to work correctly. Violating it leads to objects that 'disappear' from collections or can't be found.

Entity vs Value Object

In Domain-Driven Design, 'Entity' objects are compared by identity (a User with ID=123 is the same user even if their email changes), while 'Value Objects' are compared by value (two Money objects with the same amount and currency are interchangeable). Instance members support both patterns—the choice depends on the domain concept being modeled.

Instance Members in Concurrent Contexts

When multiple threads access the same object simultaneously, instance members become a source of race conditions and data corruption. Understanding this is critical for professional software development.

The Visibility Problem:

Modern CPUs have complex memory hierarchies with caches. When Thread A modifies account.balance, that change might sit in Thread A's CPU cache without being visible to Thread B for an indeterminate amount of time. Thread B might read stale data.

The Atomicity Problem:

Even simple operations like count++ are not atomic—they involve three steps: read current value, add one, write new value. If two threads execute count++ simultaneously on a shared object, they might both read the same initial value and both write the same result, losing one increment.

concurrency_issues
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// UNSAFE: Race conditions on instance fields
public class UnsafeCounter {
    private int count;  // Shared mutable state
    
    public void increment() {
        count++;  // NOT atomic: read → add → write
    }
    
    public int getCount() {
        return count;  // May see stale value
    }
}
 
// SAFE: Using synchronization
public class SafeCounter {
    private int count;
    
    public synchronized void increment() {
        count++;  // Only one thread at a time
    }
    
    public synchronized int getCount() {
        return count;  // Sees latest value
    }
}
 
// SAFE: Using atomic classes
public class AtomicCounter {
    private final AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.incrementAndGet();  // Atomic operation
    }
    
    public int getCount() {
        return count.get();  // Sees latest value
    }
}
 
// SAFEST: Immutable objects (no shared mutable state)
public final class ImmutablePoint {
    private final int x;
    private final int y;
    
    public ImmutablePoint(int x, int y) {
        this.x = x;
        this.y = y;
    }
    
    // No setters - state cannot change after construction
    public int getX() { return x; }
    public int getY() { return y; }
    
    // "Modification" returns new object
    public ImmutablePoint withX(int newX) {
        return new ImmutablePoint(newX, this.y);
    }
}

Thread Safety Rule

If multiple threads can access an object's instance fields, and at least one thread modifies those fields, synchronization is mandatory. The simplest approaches: (1) make the object immutable, (2) confine the object to a single thread, (3) use synchronized methods/blocks, or (4) use thread-safe data structures from java.util.concurrent.

Design Implications:

Concurrency concerns influence how we design instance members:

Prefer immutability when possible—immutable objects are inherently thread-safe
Minimize shared mutable state—the less mutable data shared between threads, the fewer synchronization problems
Consider object confinement—if only one thread ever accesses an object, no synchronization is needed
Document thread-safety expectations—clearly state whether a class is designed for concurrent access

Summary: Instance Members — Per-Object State and Behavior

We've explored instance members in depth. Let's consolidate the essential knowledge:

Key Takeaways

•Instance fields belong to individual objects — Each object created from a class has its own independent copy of instance variables. Modifying one object's fields never affects another object.
•Instance methods operate on 'this' object — They have implicit access to the object on which they're called, enabling them to read and modify that specific object's state.
•Memory allocation creates isolation — Each object occupies its own memory region on the heap. Variables hold references (pointers), not objects themselves.
•Objects can be viewed as state machines — Instance fields define current state; instance methods define valid transitions. Well-designed objects make invalid states and transitions impossible.
•Identity differs from equality — Two variables can reference the same object (identity), or different objects with the same values (equality). Both concepts matter.
•Concurrency requires careful design — Shared mutable instance fields are a primary source of race conditions. Immutability, confinement, and synchronization are the solutions.

What's Next:

Now that you understand instance members—the per-object dimension of classes—we'll explore static members: fields and methods that belong to the class itself rather than any individual object. This contrast is fundamental to object-oriented design, and understanding when to use each is a hallmark of experienced developers.

Page Complete

You now have a comprehensive understanding of instance members and their role in per-object state and behavior. You can reason about memory layout, state transitions, identity vs equality, and concurrency concerns. Next, we'll examine static members and understand when data should belong to the class rather than its instances.

Low-Level DesignStatic vs Instance Members

Static vs Instance Members

LevelBeginner

Duration50 mins

TopicStatic vs Instance Members

1 / 4

Instance Members — Per-Object State and Behavior

The Object's Personal Space

What You Will Learn

Defining Instance Members

Let's establish precise definitions:

Instance Member Definitions

•Instance Field (Instance Variable): A variable declared inside a class but outside any method, without the static modifier. Each object gets its own independent copy of this variable.
•Instance Method: A method declared without the static modifier. It operates on a specific object's instance fields and can access this (or self in Python) to reference the current object.
•Instance Context: The runtime environment in which an instance method executes, providing access to the specific object's state through implicit or explicit reference.

instance_members_example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class BankAccount {
    // Instance fields - each object has its own copy
    private String accountNumber;      // Unique to this account
    private String ownerName;          // Unique to this account
    private double balance;            // Unique to this account
    private List<Transaction> history; // Unique to this account
    
    // Instance method - operates on THIS object's data
    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        this.balance += amount;  // Modifies THIS object's balance
        this.history.add(new Transaction("DEPOSIT", amount));
    }
    
    // Instance method - reads THIS object's data
    public double getBalance() {
        return this.balance;  // Returns THIS object's balance
    }
}
 
// Usage demonstrating independence
BankAccount aliceAccount = new BankAccount("ACC-001", "Alice", 1000.0);
BankAccount bobAccount = new BankAccount("ACC-002", "Bob", 500.0);
 
aliceAccount.deposit(200.0);  // Only affects aliceAccount
System.out.println(aliceAccount.getBalance());  // 1200.0
System.out.println(bobAccount.getBalance());    // 500.0 (unchanged)

The 'this' Reference Explained

Memory Model — How Instance Members Are Stored

The Heap and Object Allocation:

In most object-oriented languages, objects live in a region of memory called the heap. When you write new BankAccount(...), the runtime:

Calculates how much memory is needed for all instance fields
Allocates a contiguous block of memory on the heap
Initializes each instance field within that block
Returns a reference (pointer) to the start of that memory block

This reference is what gets stored in your variable. The variable itself doesn't contain the object—it contains the address of the object.

Converting Mermaid diagram...

Key Memory Insights:

•Complete Isolation: Each object occupies its own memory region. Modifying aliceAccount.balance writes to memory address ~0x1000, while bobAccount.balance is at ~0x2000. They cannot accidentally interfere.
•Memory Overhead: Creating N objects means allocating memory for N copies of all instance fields. 1 million User objects with 10 fields each = 10 million field allocations. This is why understanding instance vs static matters for memory-sensitive applications.
•Reference Semantics: Variables hold references, not objects themselves. When you pass aliceAccount to a method, you're passing a copy of the reference (the address), not a copy of the object. The method can modify the original object through that reference.
•Garbage Collection: When no references point to an object, it becomes eligible for garbage collection. The heap memory is reclaimed automatically in managed languages.

The Aliasing Trap

Instance Fields — Encapsulating Object State

What Belongs in Instance Fields?

Not every piece of data should be an instance field. The guiding principle is: store data that characterizes the object's identity or state over time.

Instance Field Decision Guide
Data Characteristic	Should Be Instance Field?	Example
Unique to each object	✓ Yes	User's email address, order ID
Persists across method calls	✓ Yes	Account balance, connection status
Part of object's identity	✓ Yes	Employee ID, product SKU
Changes over object's lifetime	✓ Yes	Order status, game score
Same for all instances	✗ Use static	Tax rate, company name
Temporary computation result	✗ Use local variable	Loop counter, intermediate sum
Derived from other fields	✗ Consider computing on demand	Full name from first + last

Instance Field Categories:

Well-designed classes typically have instance fields that fall into distinct categories:

Categories of Instance Fields

•Identity Fields: Immutable data that uniquely identifies the object. Examples: userId, orderId, isbn. These are typically set once at construction and never changed.
•State Fields: Mutable data representing the object's current condition. Examples: orderStatus, connectionState, balance. These change as operations are performed.
•Configuration Fields: Settings that modify behavior but aren't core identity. Examples: maxRetries, timeout, locale. Often set at construction or through configuration methods.
•Relationship Fields: References to other objects this object is connected to. Examples: owner, parentNode, items. These encode the object graph structure.
•Cache Fields: Derived values stored for performance. Examples: cachedHashCode, fullNameCache. Must be invalidated when source data changes.

instance_field_categories
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
public class Order {
    // Identity fields - immutable, set once
    private final String orderId;
    private final Instant createdAt;
    private final Customer customer;  // Relationship field
    
    // State fields - change over time
    private OrderStatus status;
    private Instant lastUpdatedAt;
    
    // Relationship fields - connections to other objects
    private List<OrderItem> items;
    private Address shippingAddress;
    private PaymentMethod paymentMethod;
    
    // Configuration fields - behavior modifiers
    private boolean expressShipping;
    private String specialInstructions;
    
    // Cache fields - derived values for performance
    private BigDecimal cachedTotalAmount;
    private boolean totalAmountCacheValid;
    
    public Order(String orderId, Customer customer) {
        // Identity fields set at construction
        this.orderId = orderId;
        this.createdAt = Instant.now();
        this.customer = customer;
        
        // State initialized to starting values
        this.status = OrderStatus.PENDING;
        this.lastUpdatedAt = this.createdAt;
        
        // Relationships start empty
        this.items = new ArrayList<>();
        
        // Cache starts invalid
        this.totalAmountCacheValid = false;
    }
    
    public void addItem(OrderItem item) {
        this.items.add(item);
        this.lastUpdatedAt = Instant.now();
        this.totalAmountCacheValid = false;  // Invalidate cache
    }
    
    public BigDecimal getTotalAmount() {
        if (!totalAmountCacheValid) {
            // Recompute and cache
            cachedTotalAmount = items.stream()
                .map(OrderItem::getSubtotal)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
            totalAmountCacheValid = true;
        }
        return cachedTotalAmount;
    }
}

The Principle of Minimal State

Instance Methods — Operating on Object State

The Implicit this Parameter:

This mechanism is how the same deposit method code can work on any BankAccount object while affecting only the specific object it's called on.

instance_method_mechanics
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public class Counter {
    private int count;  // Instance field
    
    // Instance method - has access to 'this'
    public void increment() {
        this.count++;  // 'this' refers to the object the method was called on
    }
    
    // Instance method - 'this' is implicit if unambiguous
    public int getCount() {
        return count;  // Equivalent to 'return this.count;'
    }
    
    // Instance method - 'this' is necessary when parameter shadows field
    public void setCount(int count) {
        this.count = count;  // 'this.count' is the field, 'count' is the parameter
    }
    
    // Instance method can call other instance methods on same object
    public void incrementBy(int amount) {
        for (int i = 0; i < amount; i++) {
            this.increment();  // Calls increment() on this same object
        }
    }
}
 
// Demonstrating 'this' in action
Counter c1 = new Counter();
Counter c2 = new Counter();
 
c1.increment();  // 'this' inside increment() refers to c1
c1.increment();  // 'this' inside increment() refers to c1
c2.increment();  // 'this' inside increment() refers to c2
 
System.out.println(c1.getCount());  // 2 - c1's count
System.out.println(c2.getCount());  // 1 - c2's count

Categories of Instance Methods:

Instance methods typically fall into recognizable patterns based on their relationship to object state:

•Accessors (Getters): Read instance state without modifying it. Return field values or computed properties. Examples: getBalance(), getName(), isActive().
•Mutators (Setters/Commands): Modify instance state. Change field values, often with validation. Examples: deposit(amount), setStatus(status), addItem(item).
•Query Methods: Compute and return information based on state without modifying it. Examples: calculateInterest(), isOverdue(), getTotalItems().
•Factory Methods (on instances): Create and return new objects, often based on current state. Examples: copy(), withUpdatedAddress(newAddress), split().
•Lifecycle Methods: Handle object creation, initialization, cleanup. Examples: init(), dispose(), close().

Command-Query Separation (CQS)

Object State Transitions

The State Machine Perspective:

state_transitions_example
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
public class Order {
    public enum Status {
        PENDING,      // Initial state
        CONFIRMED,    // Payment received
        PROCESSING,   // Being prepared
        SHIPPED,      // In transit
        DELIVERED,    // Received by customer
        CANCELLED     // Terminal state (failure)
    }
    
    private Status status;
    private final List<String> statusHistory;
    
    public Order() {
        this.status = Status.PENDING;
        this.statusHistory = new ArrayList<>();
        this.statusHistory.add("Created with status: PENDING");
    }
    
    // State transition: PENDING → CONFIRMED
    public void confirm() {
        if (status != Status.PENDING) {
            throw new IllegalStateException(
                "Can only confirm PENDING orders, current: " + status);
        }
        this.status = Status.CONFIRMED;
        this.statusHistory.add("Confirmed at: " + Instant.now());
    }
    
    // State transition: CONFIRMED → PROCESSING
    public void startProcessing() {
        if (status != Status.CONFIRMED) {
            throw new IllegalStateException(
                "Can only process CONFIRMED orders, current: " + status);
        }
        this.status = Status.PROCESSING;
        this.statusHistory.add("Processing started at: " + Instant.now());
    }
    
    // State transition: PROCESSING → SHIPPED
    public void ship(String trackingNumber) {
        if (status != Status.PROCESSING) {
            throw new IllegalStateException(
                "Can only ship PROCESSING orders, current: " + status);
        }
        this.status = Status.SHIPPED;
        this.statusHistory.add("Shipped with tracking: " + trackingNumber);
    }
    
    // State transition: PENDING|CONFIRMED → CANCELLED
    public void cancel(String reason) {
        if (status != Status.PENDING && status != Status.CONFIRMED) {
            throw new IllegalStateException(
                "Cannot cancel order in status: " + status);
        }
        this.status = Status.CANCELLED;
        this.statusHistory.add("Cancelled: " + reason);
    }
    
    // Query methods for state
    public boolean canBeCancelled() {
        return status == Status.PENDING || status == Status.CONFIRMED;
    }
    
    public boolean isTerminal() {
        return status == Status.DELIVERED || status == Status.CANCELLED;
    }
}

Converting Mermaid diagram...

Enforcing Valid Transitions:

The power of this approach is that invalid transitions throw exceptions. You cannot ship a cancelled order. You cannot confirm an already-delivered order. The object protects its own consistency.

State Explosion

Object Identity and Equality

Instance members raise a fundamental question: when are two objects 'the same'? This seemingly simple question has two very different answers:

Identity vs Equality:

Identity (Reference Equality)

•Same memory location
•Exactly the same object instance
•Java: a == b
•Python: a is b
•Always fast: O(1) pointer comparison

Equality (Value Equality)

•Same meaningful content
•Logically equivalent objects
•Java: a.equals(b)
•Python: a == b
•Speed depends on implementation

identity_vs_equality
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public class Money {
    private final int cents;
    private final String currency;
    
    public Money(int cents, String currency) {
        this.cents = cents;
        this.currency = currency;
    }
    
    // Override equals for value equality
    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;  // Same identity → equal
        if (obj == null || getClass() != obj.getClass()) return false;
        Money other = (Money) obj;
        return cents == other.cents && 
               Objects.equals(currency, other.currency);
    }
    
    // Must override hashCode when overriding equals
    @Override
    public int hashCode() {
        return Objects.hash(cents, currency);
    }
}
 
// Demonstration
Money m1 = new Money(1000, "USD");
Money m2 = new Money(1000, "USD");
Money m3 = m1;  // m3 references same object as m1
 
// Identity checks
System.out.println(m1 == m2);  // false - different objects in memory
System.out.println(m1 == m3);  // true - same object
 
// Equality checks
System.out.println(m1.equals(m2));  // true - same value
System.out.println(m1.equals(m3));  // true - same value (and identity)

The HashCode Contract:

In Java and similar languages, equals and hashCode are tightly coupled. The contract states:

If a.equals(b) is true, then a.hashCode() == b.hashCode() must be true
If a.hashCode() != b.hashCode(), then a.equals(b) must be false

This contract is essential for hash-based collections like HashMap and HashSet to work correctly. Violating it leads to objects that 'disappear' from collections or can't be found.

Entity vs Value Object

Instance Members in Concurrent Contexts

The Visibility Problem:

The Atomicity Problem:

concurrency_issues
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// UNSAFE: Race conditions on instance fields
public class UnsafeCounter {
    private int count;  // Shared mutable state
    
    public void increment() {
        count++;  // NOT atomic: read → add → write
    }
    
    public int getCount() {
        return count;  // May see stale value
    }
}
 
// SAFE: Using synchronization
public class SafeCounter {
    private int count;
    
    public synchronized void increment() {
        count++;  // Only one thread at a time
    }
    
    public synchronized int getCount() {
        return count;  // Sees latest value
    }
}
 
// SAFE: Using atomic classes
public class AtomicCounter {
    private final AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.incrementAndGet();  // Atomic operation
    }
    
    public int getCount() {
        return count.get();  // Sees latest value
    }
}
 
// SAFEST: Immutable objects (no shared mutable state)
public final class ImmutablePoint {
    private final int x;
    private final int y;
    
    public ImmutablePoint(int x, int y) {
        this.x = x;
        this.y = y;
    }
    
    // No setters - state cannot change after construction
    public int getX() { return x; }
    public int getY() { return y; }
    
    // "Modification" returns new object
    public ImmutablePoint withX(int newX) {
        return new ImmutablePoint(newX, this.y);
    }
}

Thread Safety Rule

Design Implications:

Concurrency concerns influence how we design instance members:

Prefer immutability when possible—immutable objects are inherently thread-safe
Minimize shared mutable state—the less mutable data shared between threads, the fewer synchronization problems
Consider object confinement—if only one thread ever accesses an object, no synchronization is needed
Document thread-safety expectations—clearly state whether a class is designed for concurrent access

Summary: Instance Members — Per-Object State and Behavior

We've explored instance members in depth. Let's consolidate the essential knowledge:

Key Takeaways

•Instance fields belong to individual objects — Each object created from a class has its own independent copy of instance variables. Modifying one object's fields never affects another object.
•Instance methods operate on 'this' object — They have implicit access to the object on which they're called, enabling them to read and modify that specific object's state.
•Memory allocation creates isolation — Each object occupies its own memory region on the heap. Variables hold references (pointers), not objects themselves.
•Objects can be viewed as state machines — Instance fields define current state; instance methods define valid transitions. Well-designed objects make invalid states and transitions impossible.
•Identity differs from equality — Two variables can reference the same object (identity), or different objects with the same values (equality). Both concepts matter.
•Concurrency requires careful design — Shared mutable instance fields are a primary source of race conditions. Immutability, confinement, and synchronization are the solutions.

What's Next:

Page Complete