Suppose a magazine needs everything a publication has, plus an editor. Define Magazine as a subclass of Publication with `<`. Publication is its superclass; Magazine instances can use Publication’s instance methods as well as their own. section 3.5
class Publication
attr_accessor :publisher
end
class Magazine < Publication
attr_accessor :editor
end
The inherited `publisher` accessor works on a Magazine instance even though only `editor` is declared in Magazine. section 3.5
The chain can continue: `class Ezine < Magazine; end` gives Ezine instances access to methods defined in both Magazine and Publication. A subclass need not add methods; its name alone may make code more expressive. To inspect the chain, call `superclass` on a class: if `D < C` and C declares no superclass, `D.superclass` is C and `D.superclass.superclass` is Object. section 3.5 section 3.5.2
A superclass is part of method lookup, not a permanent inventory of everything an object can do. Lookup can pass through a class, included modules, and ancestral classes. An individual object can also gain a singleton method, and adding an instance method to an ancestral class can change an existing object’s capabilities. section 4.2.1 section 3.8
Choose a superclass with two constraints in mind:
- Ruby classes have only one superclass. Modules can supply additional shared methods without occupying that relationship. section 3.5.1 section 4.4.1
- An “is a” relationship can make a hierarchy clear—an Ezine is a Magazine—but inheritance also serves to share behavior. Prefer a sensible superclass over one chosen merely for a set of characteristics. section 3.8 section 4.4.1
