Methods and Valid State

The objects in the previous chapter stored information. A function can use that information to answer a question. A method gives the function a home on the class whose instances it uses.

A Method Uses the Instance’s State

Consider a small study session and a function that checks its length:

class StudySession:
    def __init__(self, subject, minutes):
        self.subject = subject
        self.minutes = minutes

def is_long(session):
    return session.minutes >= 60

session = StudySession("History", 30)
print(is_long(session))  # False

The function receives an object and reads its minutes attribute. To make the same operation a method, move the function inside the class and call its first parameter self:

This prints False and then True. In short.is_long(), Python supplies short as the self argument. The next call supplies long. One method definition can therefore answer the question for either instance.

For these ordinary methods, short.is_long() corresponds to StudySession.is_long(short). The object-method notation is the usual way to write the call. The equivalence helps explain where self comes from.

Neither call changes a session. The method reads the current state and returns a result. Practise that distinction in the following exercise.

ordinary = Package("North depot", 2, False)
priority = Package("East depot", 2, True)

print(ordinary.shipping_cost())  # 8.0
print(priority.shipping_cost())  # 18.0
print(ordinary.weight)           # 2

A Method Can Also Change State

The LoanItem from the previous chapter can gain operations too. An available item can be borrowed. An item already on loan cannot be borrowed again. Returning an item changes its availability back, but only if it was actually on loan.

This version still assumes valid nonempty text fields. Focus first on what the methods return and change:

Before stepping, predict the first call’s returned result and the value of available after it. Should those booleans be equal?

The stepper uses the same borrowing rules, with only availability shown. It leaves out the item’s text fields so you can follow one attribute, each method’s self, and the values returned to print.

The output is True, False, and True. Every call’s self refers to the same item, so each call sees the state left by the previous one. The rejected second borrow leaves that state unchanged.

Add print(camera.available) after each call in the editor to compare the returned result with the stored state.

Returned Results and Changed State Are Separate

borrow() returns a boolean describing whether this operation succeeded. It also changes available when successful.

Those are two different observable effects. The returned True is not the new value of available; a successful borrow makes availability False.

A caller can decide how to present the result:

camera = LoanItem("E10", "Camera", "media")

if camera.borrow():
    print("Item borrowed.")
else:
    print("Item could not be borrowed.")

The model is the code that represents the items and applies their rules. These methods belong to the model. The user interface receives user actions and presents results, such as the messages above. Keeping print and input outside these methods lets the same model serve a text interface, a graphical interface, or a test.

Initialization Establishes the Rule

So far, the caller has been responsible for providing valid fields. We can make initialization check that requirement. Replace LoanItem.__init__ above with this version, keeping the borrowing and returning methods:

def __init__(self, item_id, name, category):
    for value in [item_id, name, category]:
        if type(value) != str:
            raise ValueError("Item fields must be text.")
        if value.strip() == "":
            raise ValueError("Item fields must not be empty.")

    self.item_id = item_id.strip()
    self.name = name.strip()
    self.category = category.strip()
    self.available = True

Keep this method indented inside LoanItem. It rejects invalid field values before assigning the attributes. A successful item starts with nonempty trimmed text and available == True.

A property that should remain true across the supported operations is often called an invariant. Here, availability remains a boolean, and the borrowing methods preserve the intended transition between available and on-loan states.

The class does not make arbitrary external assignment impossible. This would still bypass the method:

camera.available = "maybe"

It bypasses the borrowing rules. borrow() and return_item() are public methods: operations that callers are expected to use. Callers should use them when changing availability so those rules are applied.

For these exercises, inspect attributes when needed, but use the stated methods for borrowing and returning. Later design work can choose stronger conventions about which attributes callers should use.

Check an Update Before Changing State

Initialization checks the starting state. A later update must preserve the same rules. Consider a counter that may hold only nonnegative integers:

The method checks proposed before assigning to self.value. If it raises, the previous value is still stored. The same order matters when updating an item’s name.

Expected Refusals Are Not Always Exceptions

The class call LoanItem(...) raises ValueError when its initializer rejects invalid fields. The borrowing method returns False when the item is already borrowed.

That distinction is deliberate. An ordinary attempt to borrow an unavailable item is an expected outcome of the operation, not evidence that the program cannot represent the item at all.

Other APIs might choose a different contract. What matters is making the decision explicit and testing it consistently, rather than treating every unsuccessful operation in the same way.

Apply both kinds of outcome to a new object: invalid amounts are rejected, while a valid request may be refused because of the current state. Check the amount after each operation.

Check Your Understanding

1. What supplies the self argument when camera.borrow() runs?
2. Why does successful borrowing return True but store False in availability?
3. Why should the model not print the success message itself?
4. Which rule does initialization establish before ordinary methods can run?
5. Why does checking before assignment matter for a rejected rename?