Objects: state + behavior

Written Explanation

Objects around you

Look at a desk lamp. You can describe it in two ways. First, what it is like at this moment: it is on or off, its brightness is medium, its bulb is warm white. Second, what you can do with it: switch it on, switch it off, dim it. The first list is the lamp's state. The second list is its behavior.

The Java tutorial makes the same point with real-world objects such as a dog (state: name, colour, hungry; behavior: barking, fetching) and a bicycle (state: current gear, current speed; behavior: changing gear, braking). Software objects are modeled on this idea.

• State is the data an object remembers about itself at a given moment. It can change over time.
• Behavior is what the object can do, usually by changing its state or by answering a question about it.

A useful test: state is a noun-like fact ("the balance is 10000"), behavior is a verb-like action ("deposit 2500").

Fields and methods

In a program, state is stored in fields: variables that belong to the object. Behavior is written as methods, which you already know from BEG-014. The difference from the static methods you wrote then is where they live: the methods now belong to the object and act on its own fields.

A method can change state (deposit changes the balance) or report state (describe prints the owner and balance). Both are behavior.

What is state and what is behavior? A decision rule

Ask two questions about any word in a description:

1. Is it a value that sits there and describes the thing? That is state. (balance, owner, title, brightness)
2. Is it something the thing does or has done to it? That is behavior. (deposit, borrow, switch on)

Watch for these traps:

• A calculated value such as "balance after interest" is the result of a behavior, not extra state, unless you decide to store it.
• "Is borrowed" is state (a yes/no fact). "Borrow" is behavior (the action that makes it true).
• The same real thing can have more state than your program needs. A bank account has a colour of card, but if the bank's rules never use it, you leave it out. You model only what matters for the problem.

Each object has its own state

If two objects are built the same way, each still has its own values. Ana's balance is not Omar's, even though both are accounts. Depositing into Ana's account changes Ana's balance only. This is the opposite of the parallel arrays, where the link between values was a convention: now one object holds one set of values.

Objects talk to each other

A real program has many objects, and they cooperate by calling each other's methods. A customer object asks an account object to deposit; a bank object asks one account to withdraw and another to deposit when money moves. Each call is a message of the form "object, please do this". The caller does not need to know how the balance is stored, only which method to call.

This also explains why behavior belongs with the data. The account knows its own balance, so it is the best place for the rule "you cannot withdraw more than the balance". If the rule lived somewhere else, every caller would have to remember it.

A first look at Java (preview)

The following is a preview. The next module teaches each part. Read it only to see state and behavior side by side.

class Account {
    String owner;                 // state
    int balance;                  // state
    void deposit(int amount) { balance += amount; }                              // behavior
    void describe() { System.out.println(owner + ": " + balance); }              // behavior
}

The two fields hold the state; the two methods are the behavior. Notice deposit has no parameter for the balance: it reads and changes the object's own balance.