Smalltalk-80: Objects, Messages and Methods

The book’s vocabulary

Goldberg and Robson’s Smalltalk-80 book describes objects with private memory and operations, messages that request operations, and classes describing implementations shared by instances. The receiver determines how to respond. The selected opening chapter is a language explanation, not a complete tour of every interactive tool.

Sources for this section: [1]

An invented library example

Imagine a library system with two loan objects: LoanA and LoanB. Each remembers its own due date. A caller sends the same conceptual request, “may this loan be renewed?” LoanA may answer yes and LoanB no because their remembered states differ. The caller has not needed to retrieve and edit either due-date field directly. These are explanatory names and English requests, not runnable Smalltalk source.

Now imagine that the policy for one kind of loan changes. A method handling the renewal request can change while the caller continues to make the same request. That separation is useful only if the request’s meaning remains clear. Quietly changing “renew” to mean “return the book” would break the agreement even if the message name stayed the same.

A class is not one shared due date

In the book’s account, instances of a class share a description of their form and methods, while each instance has its own state. The distinction prevents a class definition from being confused with one particular object.

Apply that distinction to the invented loans. Sharing a class does not mean that renewing LoanA should also renew LoanB. If both change, investigate whether the example deliberately shares some other object or whether the implementation has confused the two states. An identical message interface is not evidence of identical contents.

Sources for this section: [1]

Choosing objects is a design decision

For a classroom model concerned only with loan renewals, representing each loan may be enough. For a study of queues at a checkout desk, the model would also need to represent service and waiting. The useful objects depend on the question. More class names do not automatically make a model more faithful.

When reading a program description, ask four questions: who receives the message, what request it expresses, where the relevant state belongs and which method handles the request. This is a practical reading method for the historical vocabulary. It is not a claim that message passing removes every dependency, proves program correctness or dictates one universal way to model a library.