SqueakByExample:5.6
메서드 찾기는 상속 관계를 따른다
오브젝트가 메시지를 받을때는 어떤일이 일어날까요?
과정은 꽤 단순합니다: 수신자의 클래스는 메시지를 처리하기 위해 클래스가 가진 메서드중 사용할것을 검색합니다. 만약 수신자 클래스에 메세지에 적합한 메서드가 없다면, 클래스는 상위클래스에 요청하고 찾을때까지 상속관계를 따라 클래스를 거슬러 올라갑니다. 메서드를 발견 했을 때, 메서드의 매개변수로 인자를 묶어 한덩이로 만들고 가상머신은 묶인것을 실행합니다.
설명한것처럼 과정이 그리 복잡하지는 않습니다. 하지만, 몇몇 질문들은 중요한점을 지적합니다.
- 메서드가 명확하게 값을 반환하지 못할때는 어떤 일이 일어나나요?
- 클래스가 상위 클래스의 메서드를 다시 구현하면 어떤 일이 일어나나요?
- self와 super의 메시지 전송상 차이점은 무엇입니까?
- 메서드를 찾지 못하면 어떤 일이 일어나나요?
여기서 보여드린 메서드 검색규칙은 개념일 뿐입니다: 가상 머신 구현체[1]는 메서드 검색 방식의 속도를 늘리기 위해 모든 종류의 기술과 최적화를 사용합니다. 가상 머신 구현체는 이런 실질적인 최적화 작업들을 하지만, 사용자는 여기서 제시한 규칙과 다른 동작을 전혀 확인할 수 없습니다.
먼저 기본적인 검색 전략을 살펴보고, 그 다음 추가적인 질문에 대해 생각해 보겠습니다.
메서드 검색
우리가 EllipseMorph의 인스턴스를 만든다고 가정해 봅시다.
anEllipse := EllipseMorph new.
만약 defaultColor 라는 오브젝트 메시지를 보낸다면, Color yellow: 를 결과로 얻을 수 있습니다.
anEllipse defaultColorColor ⇒ yellow
클래스 EllipseMorph는 defaultColor를 실행하므로, 적합한 메서드는 수신자 클래스 내부에서 즉시 발견됩니다.
메서드 5.14: 로컬에서 실행된 메서드
EllipseMorph>>defaultColor
"answer the default color/fill style for the receiver"
↑ Color yellow
반대로, 만약 메시지 openInWorld 를 Ellipse에 보낸다면, 이 메서드는 즉시 발견되지 않습니다, 그 이유는 클래스 EllipseMorph는 openInWorld를 구현하지 않았기 때문이죠. 그러므로 메서드 검색은, openInWorld 메서드를 클래스 Morph에서 발견할 때까지, 상위 클래스 BorderedMorph 그리고 다른 클래서에서도 계속됩니다. (그림 5.2를 보십시오)
self 반환하기
EllipseMorph>>defaultColor (메서드 5.14)는 명쾌하게 Color yellow를 반환하지만, Morph>>openInWorld (메서드 5.15)는 아무것도 반환 하지 않음을 확인할 수 있습니다.
메서드 5.15: 상속된 메서드
Morph>>openInWorld
"Add this morph to the world. If in MVC, then provide a Morphic window for it."
self couldOpenInMorphic
ifTrue: [self openInWorld: self currentWorld]
ifFalse: [self openInMVC]
실제로, 메서드는 항상 값(value)로 메시지에 응답합니다-여기서 반환되는 값(value)은 당연히 오브젝트입니다. 응답은 메서드에서↑construct 의 형식으로 이미 정의되었겠지만, 실행된 시점에서 ↑를 실행하지 않고, 메서드의 끝부분에 도달했다면, 메서드는 여전히 값(value)을 내놓게 됩니다: 이 경우 메서드는 메시지를 수신한 오브젝트(수신자) 자체를 반환합니다. 이런것들을 가리켜 "answers self" 메소드 라고 합니다. 스몰토크에서, 의사 변수 self는 오히려 Java에서 this과 같기 때문에 그렇습니다.
여기서 openInWorld 메서드(메서드 5.15)는 openInWorldReturnSelf 메서드(메서드 5.15)와 동등한 취급을 받는다는걸 보여주고 있습니다.
메서드 5.16: 명시적으로 self 리턴하기
Morph>>openInWorld
"Add this morph to the world. If in MVC,
then provide a Morphic window for it."
self couldOpenInMorphic
ifTrue: [self openInWorld: self currentWorld]
ifFalse: [self openInMVC].
↑ self "Don't do this unless you mean it"
당신이 뭔가를 명시적으로 반환하려할때, 여러분은 발신자가 관심있어할만한것을 반환하며 의사소통을 하겠죠. 당신이 정확하게 self를 반환한다는 의미는, 발신자는 반환값을 사용할게 될거라고 예측하고 진행을 하게 되는것과 같습니다.[2] 이런 프로그래밍 방법은 self를 정확하게 반환하는 좋은 방법도 아닐뿐더러 여기서 다룰만한 사례도 아닙니다.
이 ↑self는 스몰토크에서 일반적인 용어이며, Kent Beck이 "흥미로운 반환 값"[3]이라고 언급한 것입니다.
재지정과 확장 (Overriding and extension)
그림 5.2에 있는 EllipseMorph 클래스 계층도을 다시 살펴보면, Morph 클래스와 EllipseMorph 클래스는 둘 다 defaultColor 를 구했음을 알 수 있습니다. Morph new openInWorld 로 새 모프를 만들면 타원은 원래 노랑색이어야 하지만 파랑색으로 만들어지는걸 확인할 수 있죠.
이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정override 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.
가끔 하위클래스를 만들때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다[4]. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)를 사용하면 가능합니다.
initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!
그러므로 하위클래스 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:
메서드 5.17: Super initialize
BorderedMorph>>initialize
"initialize the state of the receiver"
super initialize.
self borderInitialize
self sends 와 super sends
상속 받은 메서드의 동작을 재지정려면 super send 가 필요합니다. 그러나 상속 여부와 관계 없이 일반적으로 메서드를 구현하려면 self send 를 사용하면 됩니다.
self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.[5]
super 자체는 상위 클래스를 나타내는것이 아니라는것을 주의하세요! 사실 이렇게 오해할만 하기도 합니다. 또한 super 를 사용하면 수신자의 상위 클래스 내부에서 검색을 한다고 잘못 생각할 수도 있습니다.
임의의 모프로 보내질 수 있는 initString 메시지가 있다고 가정해보겠습니다:
anEllipse initString ⇒ '(EllipseMorph newBounds: (0@0 corner: 50@40) color:
Color yellow) setBorderWidth: 1 borderColor: Color black'
위의 경우 반환되는 값은 모프의 재생성 작업을 할 수 있는 문자열입니다. self와 super send의 조합을 이용한다면 어떻게 해야 정확한 결과를 얻을 수 있을까요? 먼저, 그림 5.3에 보이는 것 처럼, anEllipse initString 은 메서드 initString이 클래스 Morph에서 발견되도록 합니다.
메서드 5.18: self send
Morph>>initString
↑ String streamContents: [:s | self fullPrintOn: s]
메서드 Morph>>initString 은 fullPrintOn: 의 self send 를 수행합니다. 이 작업은 다시 원래의 수신자의 클래스인 EllipseMorph 클래스에서부터 두 번째 검색을 시작하게 하며 BorderedMorph 클래스에서 fullPrintOn: 를 찾게됩니다. (그림 5.3을 다시 보십시오)
여기서 대단히 중요한 점은, self send 가 사용되면 수신자 anEllipse 의 클래스인 EllipseMorph 클래스에서 메서드 찾기를 다시 시작하도록 만든다는 것입니다.
메서드 5.19: super와 self send 의 조합
BorderedMorph>>fullPrintOn: aStream
aStream nextPutAll: '('.
super fullPrintOn: aStream.
aStream nextPutAll: ') setBorderWidth: '; print: borderWidth;
nextPutAll: ' borderColor: ' , (self colorString: borderColor)
super send 가 사용되었기 때문에, Morph 클래스에서 super send 가 실행된 클래스의 상위 클래스에서 메서드 검색을 시작합니다. 그 다음, Morph>>fullPrintOn:를 찾고 처리합니다.
super 에 의한 메서드 검색이 수신자의 상위 클래스에서 시작되지 않음에 주의합니다. 만약 상위 클래스에서 시작한다면 무한반복으로 수렴하는, BorderedMorph에서의 검색이 시작됩니다[6].
만약 당신이 super send 와 그림 5.3 에 있는 initString 의 탐색과정을 주의깊게 보셨다면, super의 바인딩은 정적이라는걸 아셨을 겁니다: 모든문제는 super send 가 들어있는 소스코드를 가진 클래스에 있습니다. 이런 super 와는 반대로 self의 바인딩은 동적입니다: self는 항상 현재 실생중인 메세지의 수신자를 의미하며 self로 전송된 모든 메세지들에 대한 메서드 검색은 수신자 클래스 자신부터 시작된다는 의미가 됩니다.
이해할 수 없는 메시지
원하는 메시지를 발견하지 못할때는 어떤 현상이 일어날까요?
메시지 foo를 anEllipse클래스에 보낸다고 가정하겠습니다. 첫번째로 일반적인 메서드 찾기 작업은 상속 관계를 따라 Object 클래스까지(또는 ProtoObject 클래스까지도) 이 메서드검색을 위해 이동됩니다. 메서드를 발견하면, 가상 머신은 오브젝트에게 self doesNotUnderstand: #foo 를 보내게 됩니다. (그림 5.4를 봐주세요)
이런 메서드 검색에 대한 반응동작은 완벽하게 일반적인, 동적 메시지 전송 이기 때문에, 메서드 검색은 클래스 EllipseMorph 클래스부터 다시 시작되지만, 이번에는 doesNotUnderstand: 라는 메서드를 검색합니다. 그리고 보이는 것처럼, 오브젝트는 doesNotUnderstand: 메서드를 실행합니다: 이 메서드는 새로운 MessageNotUnderstood 오브젝트를 만들고, 이렇게 만들어진 MessageNotUnderstood 오브젝트는 현재의 진행 상황에서 디버거의 시작을 가능하게 합니다.
왜 이렇게 누가봐도 에러인 상황을 취급하기 위해 이 복잡한 처리과정을 거쳐야 할까요? 글쎄요, 이런 과정은 개발자에게 이런식으로 발생하는 에러를 가로채서 다른 작업을 할 수 있도록 해주는 쉬운 방법을 제공합니다. 대안을 원하는 경우, 모든 오브젝트의 서브 클래스에서 메서드 "doesNotUnderstand" 를 쉽게 재지정하고, 에러를 취급할 수 있는 다른 방법을 제공할수도 있습니다.
사실, 이런 방법은 어떤 오브젝트로부터 다른 오브젝트로 메시지 전달을 자동 위임 할 수 있도록 구현하는 쉬운 방법중 하나가 될 수 있습니다. Delegator 오브젝트는 수신자 자신이 이해하지 못하는 모든 메시지를 처리할 책임이 있는 다른 오브젝트에 넘기거나 자체적으로 오류를 발생시킵니다!
Notes
- ↑ 이 경우는 CogVM을 말하는게 되겠죠?
- ↑ 수신자와 발신자가 서로에 대해 명확하게 알아야 동작되는 상황을 피하라는 의미겠죠.
- ↑ Kent Beck, Smalltalk Best Practice Patterns. Prentice-Hall, 1997.
- ↑ 자식클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.
- ↑ self와 super에 대한 내용은 이부분 을 찾아보면 좀 더 자세히 알 수 있습니다.
- ↑ super send 가 호출된 메서드를 소유한 클래스의 상위클래스에서 메서드를 검색하기때문에 메서드 검색에 있어 무한루프에 빠지지 않는다는 의미