다형적 view

"같은 C 마이너 구절을 fretboard 와 keyboard 에. 음악은 동일해. 옷만 바뀌었어."

구체 inheritor 로서의 악기

이 레슨에서 OOP 가 코딩 패턴이길 그만두고 말 그대로 아키텍처가 돼. 음악 이론 — 모델 — 이 추상 base class 야. 각 악기 캔버스는 딱 한 가지를 아는 구체 inheritor 야: 모델을 자기 기하로 projection 하는 법. fretboard 는 노트를 줄과 프렛에 projection 해. keyboard 는 같은 노트를 흰건반·검은건반에. staff 는 줄과 칸에. 같은 노트, 세 개의 project() 구현.

교과서적 의미의 다형성이야: 인터페이스 하나("이 곡 렌더해"), 구현 여럿, view 의 타입으로 선택. fretboard 에서 keyboard 로 바꿔도 곡은 아무것도 안 변해 — 그냥 다른 서브클래스의 project() 를 부른 거야.

왜 이게 OOP-as-syntax 가 아니라 OOP-as-worldview 인가

아빠는 세상을 객체지향으로 읽어 — 언어 기능이 아니라 현실이 빚어진 방식으로. C 마이너 스케일은 추상이고, 기타리스트의 손과 피아니스트의 손은 그것의 두 구체 실현이야. 음악이 keyboard 로 옮겨갈 때 더 진짜거나 덜 진짜가 된 게 아냐 — 옷을 갈아입은 거야. Bonfire 는 그걸 코드로 그대로 만들어: 음악 모델이 base, 악기가 inheritor, 렌더링이 다형적 dispatch. (OO Quest 를 했으면, 이건 그 세계관을 특정 매체에 적용한 거야.)

보상: view 는 싸고, 모델은 귀해

view 가 순수 projection 이라서, 더하기 싸고 바꾸기 안전해. bass view 원해? 드럼 그리드? 피아노 롤? 각각 한 가지 일 — project(song) — 만 하는 새 서브클래스고, 더해도 모델한텐 비용 0 이야. 비싸고 귀하고 조심스레 지키는 건 모델이야. view 는 밑의 몸이 옳기만 하면 자유롭게 꿰매는 옷이야.

Code

다형적 projection: view 당 project() 하나·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)

# 같은 곡, 다른 projection. 내일 StaffView 추가:
# 새 서브클래스 하나, MusicModel 변경은 0.

Exercise

짧은 멜로디 하나를 골라 종이에 두 가지로 'projection' 해 봐: 여섯 줄에 프렛 번호로 쓰고, 그다음 피아노에 음이름으로 써. 방금 project() 메서드 둘을 손으로 구현한 거야. 멜로디 — 모델 — 는 안 변하고 projection 만 변한 걸 봐. 그 불변성이 핵심 전부야.

Hint

두 projection 이 멜로디에 어떤 음이 있는지를 두고 의견이 갈리면, 틀린 건 멜로디가 아니라 projection 하나야. 모델이 심판이야.