Attributes — Object State - Attributes and Methods | OneNoughtOne

0/290

System DesignClasses & Objects

Attributes and Methods

LevelBeginner

Duration60 mins

TopicClasses & Objects

1 / 4

Attributes — Object State

The Memory of Objects

Every object in an object-oriented system has a memory—a collection of data that defines what the object is at any given moment. This memory is captured through attributes, the variables that live within an object and hold its state. Understanding attributes deeply is fundamental to mastering object-oriented design.

When you look at a real-world entity—a bank account, a shopping cart, a user profile—you instinctively recognize that it has properties. A bank account has a balance, an account number, and an owner. A shopping cart has items and a total. These properties, when translated into code, become attributes—the fundamental units of object state.

What You Will Learn

By the end of this page, you will understand attributes as the carriers of object state, know how to identify appropriate attributes for your classes, distinguish between different types of attributes, and recognize the critical relationship between attributes and object identity.

Understanding Object State

State is one of the three pillars that define an object, alongside identity and behavior. An object's state is the collection of all its attribute values at a particular moment in time. This state can change as the object interacts with other objects and responds to events.

Consider a simple example: a BankAccount object. Its state might include:

An account number (which rarely changes)
A balance (which changes frequently)
An account holder name
An account status (active, frozen, closed)

At any instant, the combination of these values represents the complete state of that particular bank account. Change any one of them, and you have a different state—though the object's identity remains the same.

State vs. Identity

A crucial distinction: an object's identity persists even as its state changes. A bank account that starts with $100 and grows to $1000 is still the same bank account. The state has changed, but the identity has not. This distinction becomes especially important when we discuss object equality and hashing.

Why State Matters:

State is what gives objects meaning beyond mere code structure. A method that operates on state-less data is essentially a function in disguise. True object-orientation emerges when:

Objects remember — They retain information between method calls
State influences behavior — The same method may produce different results depending on current state
Objects can change — Mutable state allows objects to evolve over time
State can be protected — Encapsulation ensures state changes happen only through controlled interfaces

This is fundamentally different from procedural programming, where data structures and the functions that operate on them are separate entities.

What Are Attributes?

An attribute (also called a field, instance variable, or member variable depending on the language) is a variable that is declared within a class and exists for the lifetime of each object created from that class. Every instance of the class has its own copy of each attribute, with its own values.

The Technical Definition:

Attributes are variables that:

Are declared within the class body (not within methods)
Belong to instances of the class (unless marked static)
Have a type that defines what kind of values they can hold
Have a visibility that controls who can access them
Persist for the lifetime of the object

BankAccount.java
1
2
3
4
5
6
7
8
9
10
11
12
13
public class BankAccount {
    // These are attributes - they define the state each account object will hold
    
    private String accountNumber;    // Unique identifier for this account
    private String accountHolder;    // Name of the person who owns this account
    private double balance;          // Current monetary balance
    private boolean isActive;        // Whether the account is currently active
    private LocalDateTime openedOn;  // When the account was created
    
    // Each instance of BankAccount will have its own copy of these variables
    // with its own values. Two different BankAccount objects will have
    // two different accountNumber values, two different balance values, etc.
}

Key Characteristics of Attributes:

1. Instance-Specific Storage

Unlike local variables (which exist only within a method call) or class-level static variables (which are shared across all instances), attributes provide storage that is:

Unique to each object
Persistent across method calls
Initialized when the object is created
Destroyed when the object is garbage collected

2. Type Safety

Attributes have declared types that enforce what values can be stored. A balance declared as double cannot accidentally hold a String. This compile-time type checking prevents entire categories of bugs.

3. Scope and Lifetime

The scope of an attribute is the entire class body—any method can access it. The lifetime extends from object construction to object destruction. This gives attributes a fundamentally different character from local variables.

Naming Matters

Attributes should be named as nouns or noun phrases that clearly describe what they represent. Use 'balance' not 'bal', 'accountHolder' not 'ah', 'isActive' not 'flag1'. Well-named attributes serve as documentation and make code self-explanatory.

Types of Attributes

Attributes can be classified along several dimensions. Understanding these classifications helps you make better design decisions about what attributes your classes need and how they should behave.

Attribute Classification Dimensions

•By Mutability: Mutable vs Immutable — Can the value change after initialization?
•By Scope: Instance vs Static — Does each object have its own copy, or is it shared?
•By Origin: Intrinsic vs Derived — Is the value stored directly or computed from other attributes?
•By Visibility: Public, Private, Protected — Who can access this attribute?
•By Type: Primitive vs Reference — Does it hold a value directly or a reference to another object?

Mutable vs Immutable Attributes:

A mutable attribute can change its value after the object is created. The balance of a bank account is mutable—it changes with deposits and withdrawals.

An immutable attribute's value is set at creation and never changes. The accountNumber is typically immutable—once assigned, it remains constant for the life of the account.

Design insight: Prefer immutability where possible. Immutable attributes:

Are inherently thread-safe
Cannot be corrupted by bugs
Make objects easier to reason about
Enable safe sharing of objects

ImmutabilityExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class BankAccount {
    // Immutable attribute - set once, never changes
    // The 'final' keyword enforces immutability at compile time
    private final String accountNumber;
    
    // Mutable attribute - can change throughout object's lifetime
    private double balance;
    
    public BankAccount(String accountNumber, double initialBalance) {
        this.accountNumber = accountNumber;  // Can only be set here
        this.balance = initialBalance;       // Can be changed later
    }
    
    // accountNumber has no setter - it's truly immutable
    public String getAccountNumber() {
        return accountNumber;
    }
    
    // balance can change via controlled operations
    public void deposit(double amount) {
        this.balance += amount;  // State mutation happens here
    }
}

Intrinsic vs Derived Attributes:

An intrinsic (or stored) attribute holds a value directly. The balance is intrinsic—when you call getBalance(), you return the stored value.

A derived (or computed) attribute's value is calculated from other attributes. Consider netWorth that might be calculated as assets - liabilities. Derived attributes aren't stored; they're computed on demand.

Design considerations for derived attributes:

No storage cost, but has computation cost
Always consistent with source attributes (can't get stale)
May want to cache if computation is expensive and source data changes rarely

The Derived Attribute Trap

A common mistake is storing derived values as regular attributes and manually keeping them synchronized. This creates invariant maintenance burden and bugs when synchronization is forgotten. Unless caching is necessary for performance, prefer computing derived values on demand.

Instance vs Static Attributes

This distinction is fundamental and often misunderstood by developers new to OOP.

Instance Attributes:

Each object has its own copy
Different objects can have different values
Accessed through object references
Represent the state of individual objects

Static (Class) Attributes:

Only one copy exists, shared by all instances
The same value for all objects
Accessed through the class name (or instance, but discouraged)
Represent state that belongs to the class itself, not individual objects

Instance vs Static Attributes Comparison
Aspect	Instance Attribute	Static Attribute
Storage	One per object	One per class (shared)
Access	object.attribute	ClassName.attribute
Purpose	Object-specific state	Class-wide state
Initialization	In constructor	At class loading or static initializer
Memory	Scales with objects	Fixed regardless of object count
Example	account.balance	BankAccount.interestRate

StaticVsInstance.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
public class BankAccount {
    // Static attribute - shared across ALL bank accounts
    // If the interest rate changes, it changes for everyone
    private static double interestRate = 0.02;  // 2%
    
    // Static counter - tracks how many accounts have ever been created
    private static int totalAccountsCreated = 0;
    
    // Instance attributes - unique to each account
    private final String accountNumber;
    private double balance;
    
    public BankAccount(String accountNumber, double initialBalance) {
        this.accountNumber = accountNumber;
        this.balance = initialBalance;
        totalAccountsCreated++;  // Increment class-level counter
    }
    
    // Instance method using static attribute
    public double calculateYearlyInterest() {
        // Each account calculates based on its own balance
        // but uses the shared interest rate
        return this.balance * interestRate;
    }
    
    // Static method to adjust rate for all accounts
    public static void setInterestRate(double newRate) {
        interestRate = newRate;  // Affects all future interest calculations
    }
}

When to Use Static Attributes

Use static attributes sparingly and only when the value truly belongs to the class rather than individual objects. Good uses: constants (like Math.PI), counters for instances created, shared configuration values, cached expensive computations. Bad uses: anything that should vary per object, mutable shared state in multi-threaded contexts (dangerous!).

Primitive vs Reference Attributes

The type of an attribute—whether it holds a primitive value or a reference to another object—has significant design implications.

Primitive Attributes:

Hold simple values directly: int, double, boolean, char, etc. These are:

Automatically initialized to default values (0, 0.0, false)
Compared by value
Copied by value (changes to a copy don't affect the original)
Cannot be null

Reference Attributes:

Hold references to other objects. These are:

Can be null (the reference points to nothing)
Compared by reference identity by default
Copied by reference (changes through either reference affect the same object)
Enable object composition and relationships

AttributeTypes.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Order {
    // Primitive attributes
    private int orderId;           // Stores the actual number
    private double totalAmount;    // Stores the actual decimal value
    private boolean isPaid;        // Stores true or false directly
    
    // Reference attributes
    private Customer customer;     // Stores a reference to a Customer object
    private Address shippingAddress;  // Reference to an Address object
    private List<OrderItem> items;    // Reference to a list of OrderItem objects
    private LocalDateTime createdAt;  // Reference to a date-time object
    
    // The difference matters for:
    // 1. Null safety - primitives can't be null, references can
    // 2. Sharing - references can point to shared objects
    // 3. Identity - "==" means different things for primitives vs references
}

The Aliasing Problem

Reference attributes create potential for aliasing—where multiple references point to the same object. If you expose a reference (return it from a getter), external code can modify the object through that reference, potentially violating encapsulation. We address this with defensive copying, which we'll cover in the encapsulation chapter.

Design Implications:

When an attribute is a reference to another object, you're establishing a relationship:

Dependency — Your class now depends on another class
Navigation — You can navigate from one object to another
Responsibility — You must decide: does your object own the referenced object, or just use it?
Lifecycle — Should the referenced object exist independently, or only as long as your object exists?

These questions lead directly to concepts like aggregation and composition, which we'll explore in later modules.

Attributes and Object Identity

Understanding the relationship between attributes and object identity is crucial for proper object-oriented design.

The Three Aspects of an Object:

Identity — What makes this object uniquely identifiable (independent of its state)
State — The current values of all attributes
Behavior — The methods that operate on and expose the state

Key Identifiers:

Some attributes serve a special role as identifiers—values that uniquely distinguish one object from another:

A Student might be identified by studentId
A BankAccount by accountNumber
An Employee by employeeId

Identifier attributes are typically:

Unique across all instances
Immutable (set at creation, never changed)
Used for equality comparisons
Required for proper hashing in collections

IdentityExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Student {
    // The identifier - uniquely identifies this student
    private final String studentId;  // Immutable, unique
    
    // Mutable state that can change without changing identity
    private String name;      // Can change (marriage, legal name change)
    private String email;     // Can change (new email provider)
    private double gpa;       // Changes with each semester
    
    // Two students are "equal" if they have the same studentId
    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        Student other = (Student) obj;
        return studentId.equals(other.studentId);  // Identity-based equality
    }
    
    @Override
    public int hashCode() {
        return studentId.hashCode();  // Hash based on identifier
    }
}

Identify Your Identifiers Early

When designing a class, one of your first decisions should be: what uniquely identifies an instance? This identifier attribute (or combination of attributes) will guide your implementation of equals() and hashCode(), and will likely be immutable. Getting this wrong causes subtle, hard-to-debug issues with collections and caching.

Documenting Attributes

Well-documented attributes make code maintainable. Documentation should explain the purpose of an attribute, not just its type.

What to Document:

Purpose — Why does this attribute exist?
Constraints — What values are valid? What invariants must hold?
Units — If numeric, what units? (milliseconds? cents? pixels?)
Nullability — Can it be null? What does null mean?
Mutability — Is it ever changed after construction?
Thread-safety — Is it safe for concurrent access?

WellDocumentedAttributes.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
public class Reservation {
    /**
     * Unique identifier for this reservation.
     * Assigned at creation and never changes.
     * Format: "RES-" followed by 8 alphanumeric characters.
     * Used as the primary key in persistence.
     */
    private final String reservationId;
    
    /**
     * The date and time when the reservation starts.
     * Always in UTC timezone.
     * Must be in the future at creation time.
     * Cannot be changed after confirmation.
     */
    private LocalDateTime startTime;
    
    /**
     * The total price in cents (to avoid floating-point issues).
     * Always non-negative.
     * Updated when items are added/removed before confirmation.
     * Becomes immutable after confirmation.
     */
    private int totalPriceCents;
    
    /**
     * Reference to the customer making this reservation.
     * Never null - every reservation must have a customer.
     * This is an association, not a composition - customer
     * lifecycle is independent of reservation lifecycle.
     */
    private Customer customer;
}

Documentation as Design Tool

If you find an attribute hard to document clearly, that's a design smell. It may indicate the attribute's purpose is unclear, it's doing too much, or it belongs in a different class. Clear documentation forces clear thinking.

Summary: Attributes as Object State

We've explored attributes comprehensively. Let's consolidate the key insights:

Key Takeaways

•Attributes are the memory of objects — They hold the state that persists across method calls and defines what an object is at any moment.
•Distinguish mutable from immutable — Prefer immutability for attributes that shouldn't change; it prevents bugs and simplifies reasoning.
•Instance attributes belong to objects; static to classes — Use static only when the value genuinely belongs to the class itself, not to instances.
•Reference attributes create relationships — When one object holds a reference to another, you're establishing dependencies and navigation paths.
•Some attributes serve as identifiers — These uniquely identify instances and guide equality/hashing implementations.
•Good documentation captures intent — Document purpose, constraints, units, nullability, and mutability.

What's Next:

Attributes are only half the story. While attributes capture what an object knows, methods define what an object can do. In the next page, we'll explore methods—the behaviors that operate on object state and provide the interface through which objects interact with the world.

Page Complete

You now understand attributes as the fundamental carriers of object state. You can distinguish instance from static, mutable from immutable, and primitive from reference attributes. Next, we'll explore methods—the behaviors that bring objects to life.