The Well-Grounded Rubyist

Notice that our class’s name is a noun, whereas the module’s name is an adjective. Neither of these practices is mandatory, but they’re both common. Rubyists often use adjectives for module names to reinforce the notion that the module defines a behavior. What we end up with, expressed in everyday language, is a kind of predicate on the class: Stac

The objects true and false often serve as return values for conditional expressions. The object nil is a kind of “nonobject” indicating the absence of a value or result. false and nil cause a conditional expression to evaluate as false; all other objects (including true, of course, but also including 0 and empty strings) cause it to evaluate to tru

Let’s say we decide to establish a list of predefined venues for the Ticket class—a list that every ticket object can refer to and select from. We can assign the list to a constant. Constant definitions usually go at or near the top of a class definition: class Ticket VENUES = ["Convention Center", "Fairgrounds", "Town Hall

Designing object-oriented software is largely a matter of figuring out what you want your objects to be: what they should do, how they’ll interact with each other, how many of each there should be (for example, many students, one registrar), and other such questions. As you’ll see, Ruby provides a complete set of tools for naming, creating, address

Ruby doesn’t allow multiple inheritance; every Ruby class can have only one superclass, in keeping with the principle of single inheritance.

Local variable names start with a lowercase letter or an underscore and are made up of alphanumeric characters and underscores.

Our price= method can be described as an attribute writer method.

(Even better, because we don’t need instances of Temperature at all, would be to use a module—a kind of “instanceless” class, which you’ll learn about in detail in chapter 4.)

Creating your own global variables can be tempting, especially for beginning programmers and people learning a new language (not just Ruby, either). But that’s rarely a good or appropriate choice.

The issue at hand is that it’s useful to have a way to maintain state in a class. You saw this even in the simple Car class example. We wanted somewhere to stash class-relevant information, like the makes of cars and the total number of cars manufactured.