Attributes and Methods - Learning Module

Loading content...

0/246

Methods — Object Behavior

The Actions of Objects

If attributes give objects their memory, methods give objects their life. Methods are the behaviors, actions, and capabilities that objects possess. They are the verbs to the attributes' nouns—the doing that complements the being.

Consider a real-world bank account. It doesn't just have a balance; it can deposit, withdraw, transfer, and calculate interest. These are behaviors—things the account can do. In code, these behaviors become methods: functions that belong to objects and operate on their state.

What You Will Learn

By the end of this page, you will understand methods as the mechanism for object behavior, know the different types of methods and when to use each, understand how methods interact with object state, and recognize the principles that guide good method design.

What Are Methods?

A method is a function that is declared within a class and defines behavior for objects of that class. Unlike standalone functions in procedural programming, methods:

Belong to objects — Each method is associated with a specific class
Access object state — Methods can read and modify the object's attributes
Operate in context — Methods execute in the context of a specific object instance
Provide interface — Methods define how the outside world interacts with objects

The Technical Definition:

Methods consist of:

A name that describes what the method does
A return type (or void if no value is returned)
Zero or more parameters
A body containing the implementation
Access modifiers controlling visibility

MethodAnatomy.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class BankAccount {
    private String accountNumber;
    private double balance;
    
    // Method anatomy breakdown:
    // [access modifier] [return type] [name]([parameters]) { [body] }
    
    public double deposit(double amount) {   // public: visible everywhere
                                            // double: returns a number
                                            // deposit: descriptive verb name
                                            // amount: parameter needed to perform action
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit amount must be positive");
        }
        this.balance += amount;    // Modifies object state
        return this.balance;       // Returns the new balance
    }
    
    // 'this' keyword refers to the current object instance
    // The same method code works for any BankAccount object,
    // but operates on that specific object's attributes
}

The this Reference:

Inside a method, the keyword this refers to the object on which the method was called. When you write account1.deposit(100), within the deposit method, this refers to account1. This is how the same method code can work for millions of different bank account objects—each invocation operates on a different this.

This implicit context is what separates methods from functions. A function receives all its data through parameters. A method receives data through parameters plus the implicit object context.

Types of Methods

Methods can be classified by their purpose and relationship to object state. Understanding these categories helps you design classes with intention.

Method Classifications

•Accessors (Getters) — Return attribute values without modifying state
•Mutators (Setters) — Modify attribute values
•Constructors — Initialize new objects
•Query Methods — Return computed information without side effects
•Command Methods — Perform actions that change state or have side effects
•Factory Methods — Create and return new objects
•Utility Methods — Helper methods that support other methods

Query vs Command (CQS Principle):

A powerful design principle distinguishes between two fundamental method types:

Query methods answer questions about the object without changing it. Calling a query multiple times has no effect—it's like looking at a clock; looking doesn't change the time.
Command methods tell the object to do something that changes state or produces side effects. Calling a command changes the world.

The Command-Query Separation (CQS) principle suggests that methods should be either queries or commands, but not both. This separation makes code easier to reason about—you know that getters are safe to call without consequences.

QueryVsCommand.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
public class ShoppingCart {
    private List<Item> items = new ArrayList<>();
    private double totalPrice;
    
    // QUERY METHODS - Ask questions, don't change state
    public int getItemCount() {
        return items.size();  // Pure query - no side effects
    }
    
    public double getTotalPrice() {
        return totalPrice;  // Returns current state
    }
    
    public boolean isEmpty() {
        return items.isEmpty();  // Computed query
    }
    
    public Item getMostExpensiveItem() {
        return items.stream()
            .max(Comparator.comparing(Item::getPrice))
            .orElse(null);  // Complex query, still no mutation
    }
    
    // COMMAND METHODS - Change state, should not return queries
    public void addItem(Item item) {
        items.add(item);
        totalPrice += item.getPrice();  // State mutation
    }
    
    public void removeItem(Item item) {
        if (items.remove(item)) {
            totalPrice -= item.getPrice();
        }
    }
    
    public void clear() {
        items.clear();
        totalPrice = 0;  // Reset state
    }
    
    // VIOLATION of CQS - both queries and commands (avoid this)
    // public Item removeAndReturnMostExpensive() { ... }
}

Pragmatic CQS

Pure CQS isn't always practical. Stack.pop() is a classic example that both modifies state (removes element) and returns a value (the removed element). The principle is a guideline, not a law. When you violate it, do so consciously and document it.

Method Signatures and Contracts

A method's signature is its external interface—what callers need to know to use it correctly. A method's contract goes deeper, specifying the rules and promises that govern its use.

Components of a Signature:

Method name — What it's called
Parameter types and order — What inputs it requires
Return type — What output it provides
Exceptions declared — What errors it might throw
Visibility — Who can call it

The Method Contract:

Beyond the signature, every method has an implicit or explicit contract consisting of:

Preconditions — What must be true before calling the method

Parameter constraints (non-null, positive, within range)
Object state requirements (account must be active)

Postconditions — What will be true after the method returns

State changes made
Values returned

Invariants — What remains constant

Properties that hold before and after execution

MethodContract.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
public class BankAccount {
    private double balance;
    private boolean isActive;
    
    /**
     * Withdraws the specified amount from this account.
     *
     * PRECONDITIONS:
     * - amount > 0 (positive withdrawal)
     * - amount <= balance (sufficient funds)
     * - account must be active
     *
     * POSTCONDITIONS:
     * - balance is reduced by amount
     * - returns the new balance
     *
     * INVARIANT:
     * - balance >= 0 (never negative)
     *
     * @param amount the amount to withdraw (must be positive)
     * @return the new balance after withdrawal
     * @throws IllegalArgumentException if amount is not positive
     * @throws IllegalStateException if account is not active
     * @throws InsufficientFundsException if balance < amount
     */
    public double withdraw(double amount) {
        // Validate preconditions
        if (amount <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
        if (!isActive) {
            throw new IllegalStateException("Account is not active");
        }
        if (amount > balance) {
            throw new InsufficientFundsException("Insufficient funds");
        }
        
        // Execute the operation
        balance -= amount;
        
        // Postcondition is guaranteed: balance reduced by amount
        // Invariant maintained: balance cannot go negative due to precondition check
        
        return balance;
    }
}

Design by Contract

The concept of preconditions, postconditions, and invariants comes from 'Design by Contract,' pioneered by Bertrand Meyer. When contracts are explicit and enforced, bugs become easier to find because violations are detected early, close to the source.

Instance vs Static Methods

Just as attributes can be instance or static, methods can too. The distinction is fundamental:

Instance Methods:

Operate in the context of a specific object
Can access both instance and static members
Called on objects: account.deposit(100)
Can use this to refer to the current object

Static Methods:

Belong to the class, not to any specific object
Can only access static members directly
Called on the class: Math.sqrt(16)
Cannot use this (no object context exists)

Instance vs Static Methods Comparison
Aspect	Instance Method	Static Method
Context	Operates on a specific object	No object context
Access	Instance + static members	Static members only
Call syntax	object.method()	ClassName.method()
'this' keyword	Available (refers to object)	Not available
Polymorphism	Supports overriding	Does not support overriding
Use case	Object behavior	Utility, factory, pure functions

StaticVsInstanceMethods.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
public class Temperature {
    private double celsius;  // Instance attribute
    
    // Instance method - works with this object's state
    public double toCelsius() {
        return this.celsius;  // Accesses instance state
    }
    
    public double toFahrenheit() {
        return this.celsius * 9/5 + 32;  // Computes from instance state
    }
    
    // Static utility methods - pure conversion, no object needed
    public static double celsiusToFahrenheit(double celsius) {
        return celsius * 9/5 + 32;  // No 'this', no instance state
    }
    
    public static double fahrenheitToCelsius(double fahrenheit) {
        return (fahrenheit - 32) * 5/9;
    }
    
    // Static factory method - creates objects
    public static Temperature fromFahrenheit(double fahrenheit) {
        Temperature temp = new Temperature();
        temp.celsius = fahrenheitToCelsius(fahrenheit);
        return temp;  // Returns a new instance
    }
}
 
// Usage:
// Instance method: Temperature temp = new Temperature(100);
//                  double f = temp.toFahrenheit();
// Static method:   double f = Temperature.celsiusToFahrenheit(100);
// Factory method:  Temperature temp = Temperature.fromFahrenheit(212);

Overusing Static Methods

Excessive static methods indicate procedural thinking disguised as OOP. If a class is mostly static methods operating on data passed as parameters, ask: should this data be in objects with instance methods instead? Static methods have their place (utilities, factories), but instance methods are the heart of OOP.

Parameters and Return Values

Methods communicate with their callers through parameters (input) and return values (output). Designing these interfaces well is critical for usable, maintainable code.

Parameter Design Principles:

Minimal but sufficient — Include only parameters the method genuinely needs
Clear types — Use specific types that convey constraints
Logical ordering — Most important or required parameters first
Null handling — Be explicit about whether null is acceptable

Poor Parameter Design

•Too many parameters (> 4 is a code smell)
•Boolean parameters that control behavior
•Null used as a valid value
•Parameters that are always passed together
•Same type repeated (easy to mix up)

Good Parameter Design

•Few, focused parameters
•Separate methods instead of boolean flags
•Use Optional or @Nullable annotations
•Group related parameters into objects
•Distinct types or named arguments

ParameterDesign.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
// POOR: Too many parameters, boolean flag, easy to mix up strings
public void createUser(String firstName, String lastName, String email,
                       String phone, String address, boolean isAdmin,
                       boolean sendWelcomeEmail, boolean requirePasswordChange) {
    // Callers will write: createUser("John", "Doe", "email", "phone", "addr", true, false, true)
    // What does true, false, true mean? Which string is which?
}
 
// BETTER: Parameter object + separate methods
public class UserCreationRequest {
    private final Name name;          // Groups first + last
    private final ContactInfo contact; // Groups email + phone + address
    private final UserRole role;       // Enum instead of boolean
    
    // Builder pattern for clean construction
    public static Builder builder() { ... }
}
 
public void createUser(UserCreationRequest request) {
    // Single parameter, self-documenting
}
 
public void sendWelcomeEmail(User user) { ... }  // Separate concern
public void requirePasswordChange(User user) { ... }  // Separate concern

Return Value Design:

Return meaningful values — Prefer returning useful information over void
Never return null for collections — Return empty collections instead
Use Optional for absent values — Make the possibility of absence explicit
Consider fluent returns — Return this to enable method chaining where appropriate
Document exceptional returns — What does null/empty/zero mean?

The Parameter Object Pattern

When a method needs more than 3-4 parameters, consider creating a parameter object—a simple class that bundles related parameters. This makes calls readable, allows named construction (via builders), and makes it easy to add optional parameters later without changing the signature.

Method Visibility

Method visibility determines who can call a method. This is fundamental to encapsulation—hiding implementation details while exposing a clean interface.

The Visibility Levels (Java/C#):

Method Visibility Levels
Modifier	Same Class	Same Package	Subclass	Everywhere
private	✓	✗	✗	✗
(default)	✓	✓	✗	✗
protected	✓	✓	✓	✗
public	✓	✓	✓	✓

Design Principle: Minimize Visibility

Start with the most restrictive visibility that works. Make methods private by default and only increase visibility when there's a genuine need.

Why?

Public methods become part of your API contract—changing them can break callers
Private methods can be refactored freely—no external dependencies
Fewer public methods = smaller surface area = easier to understand and maintain
You can always increase visibility later; decreasing it breaks backward compatibility

MethodVisibility.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
public class Order {
    private List<Item> items = new ArrayList<>();
    
    // PUBLIC: Part of the external interface
    // Callers depend on this; changing it breaks things
    public void addItem(Item item) {
        validateItem(item);       // Calls private method
        items.add(item);
        recalculateTotal();       // Calls private method
    }
    
    // PRIVATE: Implementation detail, not part of interface
    // Can be refactored, renamed, or removed without breaking callers
    private void validateItem(Item item) {
        if (item == null) {
            throw new IllegalArgumentException("Item cannot be null");
        }
        if (item.getPrice() < 0) {
            throw new IllegalArgumentException("Item price cannot be negative");
        }
    }
    
    // PRIVATE: Internal computation, may change frequently
    private void recalculateTotal() {
        // Implementation can change freely
    }
    
    // PROTECTED: Visible to subclasses for customization points
    protected double calculateDiscount() {
        return 0.0;  // Subclasses can override to implement custom discounts
    }
}

Interface vs Implementation

Think of public methods as promises you make to the world. Every public method is a commitment. Private methods are implementation details—free to change. The distinction between interface (public) and implementation (private) is fundamental to maintainable software.

How Methods Interact with State

The interplay between methods and attributes is the heart of OOP. Methods read, modify, compute from, and protect object state.

Patterns of State Interaction:

Read state — Query methods that return attribute values or derived computations
Modify state — Command methods that change attribute values
Validate state — Methods that ensure state remains consistent
Transition state — Methods that move the object through lifecycle states
Guard state — Methods that prevent invalid state transitions

StateInteraction.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
public class Order {
    // STATE ATTRIBUTES
    private OrderStatus status = OrderStatus.DRAFT;
    private List<Item> items = new ArrayList<>();
    private double total;
    private LocalDateTime submittedAt;
    private LocalDateTime completedAt;
    
    // READ STATE - returns current attribute value
    public OrderStatus getStatus() {
        return status;
    }
    
    // DERIVED READ - computes from state
    public int getItemCount() {
        return items.size();
    }
    
    // MODIFY STATE - with validation
    public void addItem(Item item) {
        guardDraftStatus();  // Can only modify drafts
        items.add(item);
        recalculateTotal();  // Maintain consistency
    }
    
    // TRANSITION STATE - move through lifecycle
    public void submit() {
        guardDraftStatus();
        validateForSubmission();
        this.status = OrderStatus.SUBMITTED;
        this.submittedAt = LocalDateTime.now();
    }
    
    public void complete() {
        if (status != OrderStatus.SUBMITTED) {
            throw new IllegalStateException("Can only complete submitted orders");
        }
        this.status = OrderStatus.COMPLETED;
        this.completedAt = LocalDateTime.now();
    }
    
    // GUARD STATE - prevent invalid operations
    private void guardDraftStatus() {
        if (status != OrderStatus.DRAFT) {
            throw new IllegalStateException(
                "Can only modify orders in DRAFT status, current: " + status
            );
        }
    }
    
    // VALIDATE STATE - ensure consistency
    private void validateForSubmission() {
        if (items.isEmpty()) {
            throw new IllegalStateException("Cannot submit empty order");
        }
    }
    
    // MAINTAIN CONSISTENCY - keep derived state accurate
    private void recalculateTotal() {
        this.total = items.stream()
            .mapToDouble(Item::getPrice)
            .sum();
    }
}

State Consistency

Every time you modify state, ask: does this leave the object in a consistent state? If multiple attributes must change together, they should change atomically within a method. Never leave an object in an inconsistent intermediate state visible to callers.

Summary: Methods as Object Behavior

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

Key Takeaways

•Methods define what objects can do — They are the behavioral counterpart to attributes' state.
•Distinguish queries from commands — Queries return information; commands change state. Separating these clarifies design.
•Method contracts specify rules — Preconditions, postconditions, and invariants define how methods should be used.
•Instance methods operate on objects; static on classes — Use static sparingly, for utilities and factories.
•Design parameters and returns carefully — Few parameters, meaningful returns, explicit null handling.
•Minimize visibility — Start private, expand only when necessary. Public methods are commitments.
•Methods and state are intertwined — Methods read, modify, validate, and protect object state.

What's Next:

Now that we understand both attributes and methods individually, we'll explore how to design them together. The next page covers designing meaningful attributes—how to choose which attributes a class needs and how to ensure they serve the class's purpose well.

Page Complete

You now understand methods as the mechanism for object behavior. You can classify methods by purpose, design clean signatures and contracts, choose appropriate visibility, and reason about how methods interact with state. Next, we'll design meaningful attributes.