Polymorphic Views

"The same C-minor passage, on a fretboard and on a keyboard. The music is identical. Only the clothing changed."

Instrument as a Concrete Inheritor

This is the lesson where OOP stops being a coding pattern and becomes the literal architecture. Music theory — the model — is the abstract base class. Each instrument canvas is a concrete inheritor that knows one thing: how to project the model into its own geometry. The fretboard projects notes onto strings and frets. The keyboard projects the same notes onto white and black keys. The staff projects them onto lines and spaces. Same notes, three project() implementations.

That's polymorphism in the textbook sense: one interface ("render this song"), many implementations, chosen by the type of view. Nothing about the song changes when you switch from fretboard to keyboard — you've just called a different subclass's project().

Why This Is OOP-as-Worldview, Not OOP-as-Syntax

Dad reads the world through object orientation — not as a language feature but as how reality is shaped. A C-minor scale is an abstract thing; a guitarist's hand and a pianist's hand are two concrete realizations of it. The music didn't get more or less real when it moved to the keyboard; it got re-clothed. Bonfire just makes that literal in code: the music model is the base, the instruments are the inheritors, and the rendering is polymorphic dispatch. (If you've done OO Quest, this is that worldview applied to a specific medium.)

The Payoff: Views Are Cheap, the Model Is Precious

Because views are pure projections, they're cheap to add and safe to change. Want a bass view? A drum grid? A piano-roll? Each is a new subclass with one job — project(song) — and adding it costs the model nothing. The expensive, precious, carefully-guarded thing is the model. The views are clothing you can sew freely once the body underneath is right.

Code

Polymorphic projection: one project() per view·python

from abc import ABC, abstractmethod

class InstrumentView(ABC):
    @abstractmethod
    def project(self, song: MusicModel) -> Geometry: ...

class FretboardView(InstrumentView):
    def project(self, song):
        return frets_for(song.notes, tuning=STANDARD)

class KeyboardView(InstrumentView):
    def project(self, song):
        return keys_for(song.notes)

# Same song, different projection. Add a StaffView tomorrow:
# one new subclass, zero changes to MusicModel.

Exercise

Pick one short melody and 'project' it two ways on paper: write it as fret numbers on six strings, then as note names on a piano. You just implemented two project() methods by hand. Notice that the melody — the model — never changed; only the projection did. That invariance is the whole point.

Hint

If your two projections disagree about which notes are in the melody, one of your projections is buggy — not the melody. The model is the referee.