다형적 view

"같은 C 마이너 구절을 fretboard에도, keyboard에도. 음악은 똑같아. 옷만 바뀌었어."

부모를 상속받은 악기들

이 레슨에서 OOP는 코딩 패턴이길 그만두고 말 그대로 아키텍처가 돼. 음악 이론, 곧 모델이 추상 부모 클래스야. 악기 캔버스는 그걸 상속받은 자식이고, 아는 게 딱 하나야. 모델을 자기 기하로 투영하는 법. fretboard는 노트를 줄과 프렛에 투영해. keyboard는 같은 노트를 흰건반과 검은건반에 투영해. staff는 줄과 칸에 투영하지. 같은 노트에 project() 구현이 세 개인 거야.

교과서에 나오는 그 다형성이야. 인터페이스는 하나("이 곡 렌더해"), 구현은 여럿, 어느 걸 쓸지는 view의 타입이 골라. fretboard에서 keyboard로 바꿔도 곡은 하나도 안 변해. 그냥 다른 자식의 project()를 부른 것뿐이야.

문법으로서의 OOP가 아니라 세계관으로서의 OOP

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

보상. view는 싸고 모델은 귀해

view가 순수한 투영이라 더하기 싸고 바꾸기 안전해. bass view가 필요해? 드럼 그리드? 피아노 롤? 전부 project(song) 하나만 하는 새 자식이고, 몇 개를 더해도 모델이 치르는 비용은 없어. 비싸고 귀해서 조심스럽게 지켜야 하는 건 모델이야. view는 밑에 있는 몸만 제대로 잡혀 있으면 얼마든지 지어 입힐 수 있는 옷이야.

Code

다형적 투영. 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)

# 같은 곡, 다른 투영. 내일 StaffView를 더해도
# 새 자식 클래스 하나면 되고, MusicModel은 그대로야.

Exercise

짧은 멜로디 하나를 골라서 종이에 두 가지로 '투영'해 봐. 먼저 여섯 줄에 프렛 번호로 쓰고, 그다음 피아노 음이름으로 써. 방금 project() 메서드를 둘 손으로 구현한 거야. 멜로디는, 곧 모델은 그대로인데 투영만 바뀐 걸 봐. 모델이 변하지 않는다는 그 점이 핵심 전부야.

Hint

두 투영이 멜로디에 어떤 음이 있는지를 두고 서로 다르게 말하면, 틀린 건 멜로디가 아니라 투영 한쪽이야. 심판은 모델이야.