SqueakByExample:5.6 - Revision history

Onionmixer: 용어수정

2013-09-17T01:58:47Z

용어수정

Onionmixer: 번역교정

2013-09-17T01:48:45Z

번역교정

← Older revision		Revision as of 01:48, 17 September 2013
Line 5:		Line 5:
	과정은 꽤 단순합니다: 수신자의 클래스는 메시지를 처리하기 위해 클래스가 가진 메서드중 사용할것을 검색합니다. 만약 수신자 클래스에 메세지에 적합한 메서드가 없다면, 클래스는 상위클래스에 요청하고 찾을때까지 상속관계를 따라 클래스를 거슬러 올라갑니다. 메서드를 발견 했을 때, 메서드의 매개변수로 인자를 묶어 한덩이로 만들고 가상머신은 묶인것을 실행합니다.		과정은 꽤 단순합니다: 수신자의 클래스는 메시지를 처리하기 위해 클래스가 가진 메서드중 사용할것을 검색합니다. 만약 수신자 클래스에 메세지에 적합한 메서드가 없다면, 클래스는 상위클래스에 요청하고 찾을때까지 상속관계를 따라 클래스를 거슬러 올라갑니다. 메서드를 발견 했을 때, 메서드의 매개변수로 인자를 묶어 한덩이로 만들고 가상머신은 묶인것을 실행합니다.

	~~설명한것처럼~~ 과정이 그리 복잡하지는 않습니다. 하지만, 몇몇 질문들은 중요한점을 ~~지적합니다~~.		설명과는 다르게 과정이 그리 복잡하지는 않습니다. 하지만, 몇몇 질문들은 중요한점을 알려주고 있죠.

	* 메서드가 명확하게 값을 반환하지 못할때는 어떤 일이 일어나나요?		* 메서드가 명확하게 값을 반환하지 못할때는 어떤 일이 일어나나요?

Onionmixer: 용어수정

2013-09-17T01:48:14Z

용어수정

← Older revision		Revision as of 01:48, 17 September 2013
Line 103:		Line 103:
	가끔 서브클래스를 만들 때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주3">자식 클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은 경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 객체 지향 언어들처럼, 이 작업 역시 super send를 사용하면 가능합니다.		가끔 서브클래스를 만들 때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주3">자식 클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은 경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 객체 지향 언어들처럼, 이 작업 역시 super send를 사용하면 가능합니다.

	initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. ~~하위클래스는~~ 상속 인스턴스 변수를 초기화 할 권리가 없습니다!		initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 서브클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!

	그러므로 ~~하위클래스~~ 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:		그러므로 서브클래스 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:

Onionmixer: 용어수정

2013-09-17T01:45:28Z

용어수정

New page

==메서드 탐색은 상속 관계를 따릅니다==

객체가 메시지를 받을 때는 어떤 일이 일어날까요?

과정은 꽤 단순합니다: 수신자의 클래스는 메시지를 처리하기 위해 클래스가 가진 메서드중 사용할것을 검색합니다. 만약 수신자 클래스에 메세지에 적합한 메서드가 없다면, 클래스는 상위클래스에 요청하고 찾을때까지 상속관계를 따라 클래스를 거슬러 올라갑니다. 메서드를 발견 했을 때, 메서드의 매개변수로 인자를 묶어 한덩이로 만들고 가상머신은 묶인것을 실행합니다.

설명한것처럼 과정이 그리 복잡하지는 않습니다. 하지만, 몇몇 질문들은 중요한점을 지적합니다.

* 메서드가 명확하게 값을 반환하지 못할때는 어떤 일이 일어나나요?
* 클래스가 상위 클래스의 메서드를 다시 구현하면 어떤 일이 일어나나요?
* self와 super의 메시지 전송상 차이점은 무엇입니까?
* 메서드를 찾지 못하면 어떤 일이 일어나나요?

여기서 보여드린 메서드 검색규칙은 개념일 뿐입니다: 가상 머신 구현체<ref name="역자주1">이 경우는 CogVM을 말하는게 되겠죠?</ref>는 메서드 검색 방식의 속도를 늘리기 위해 모든 종류의 기술과 최적화를 사용합니다. 가상 머신 구현체는 이런 실질적인 최적화 작업들을 하지만, 사용자는 여기서 제시한 규칙과 다른 동작을 전혀 확인할 수 없습니다.

먼저 기본적인 검색 전략을 살펴보고, 그 다음 추가적인 질문에 대해 생각해 보겠습니다.

===메서드 검색===

우리가 EllipseMorph의 인스턴스를 만든다고 가정해 봅시다.

<syntaxhighlight lang="smalltalk">
anEllipse := EllipseMorph new.
</syntaxhighlight>

만약 defaultColor 라는 객체 메시지를 보낸다면, '''Color yellow:''' 를 결과로 얻을 수 있습니다.

<syntaxhighlight lang="smalltalk">
anEllipse defaultColorColor ⇒ yellow
</syntaxhighlight>

클래스 EllipseMorph는 defaultColor를 실행하므로, 적합한 메서드는 수신자 클래스 내부에서 즉시 발견됩니다.

메서드 5.14: 로컬에서 실행된 메서드
<syntaxhighlight lang="smalltalk">
EllipseMorph>>defaultColor
"answer the default color/fill style for the receiver"
↑ Color yellow
</syntaxhighlight>

반대로, 만약 메시지 openInWorld 를 Ellipse에 보낸다면, 이 메서드는 즉시 발견되지 않습니다, 그 이유는 클래스 EllipseMorph는 openInWorld를 구현하지 않았기 때문이죠. 그러므로 메서드 검색은, openInWorld 메서드를 클래스 Morph에서 발견할 때까지, 상위 클래스 BorderedMorph 그리고 다른 클래서에서도 계속됩니다. (그림 5.2를 보십시오)

[[image:openInWorldLookup.png|none|800px|thumb|그림5.2: 메서드 lookup 은 상속받은 상속관계를 따릅니다]]

===self 반환하기===

EllipseMorph>>defaultColor (메서드 5.14)는 명쾌하게 Color yellow를 반환하지만, Morph>>openInWorld (메서드 5.15)는 아무것도 반환 하지 않음을 확인할 수 있습니다.

메서드 5.15: 상속된 메서드
<syntaxhighlight lang="smalltalk">
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]
</syntaxhighlight>

실제로, 메서드는 항상 값(value)으로 메시지에 응답합니다 - 여기서 반환되는 값(value)은 당연히 객체입니다. 응답은 메서드에서↑construct 의 형식으로 이미 정의되었겠지만, 실행된 시점에서 ↑를 실행하지 않고, 메서드의 끝부분에 도달했다면, 메서드는 여전히 값(value)을 내놓게 됩니다: 이 경우 메서드는 메시지를 수신한 객체(수신자) 자체를 반환합니다. 이런것들을 가리켜 "answers self" 메소드 라고 합니다. 스몰토크에서, 의사 변수 self는 오히려 Java에서 this과 같기 때문에 그렇습니다.

여기서 openInWorld 메서드(메서드 5.15)는 openInWorldReturnSelf 메서드(메서드 5.15)와 동일하게 취급함을 보여주고 있습니다.

메서드 5.16: 명시적으로 self 리턴하기
<syntaxhighlight lang="smalltalk">
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"
</syntaxhighlight>

여러분이 뭔가를 분명하게 반환하려면, 발신자가 관심있어 할 만한 것을 반환하며 의사소통을 하겠죠. 당신이 정확하게 self를 반환한다는 의미는, 발신자는 반환값을 사용할게 될 거라고 예측하고 진행을 하는 것과 같습니다.<ref name="역자주2">수신자와 발신자가 서로에 대해 명확하게 알아야 동작되는 상황을 피하라는 의미겠죠.</ref> 이런 프로그래밍 방법은 self를 정확하게 반환하는 좋은 방법도 아닐뿐더러 여기서 다룰만한 사례도 아닙니다.

이 ↑self는 스몰토크에서 일반적인 용어이며, Kent Beck이 "흥미로운 반환 값"<ref name="주석5-3">Kent Beck, Smalltalk Best Practice Patterns. Prentice-Hall, 1997.</ref>이라고 언급한 것입니다.

<center>{{HighlightDoubleBox|전송자가 값을 사용하기를 원할 때에만 값을 반환하면 됩니다.}}</center>

===재지정 및 확장(Overriding and extension)===

그림 5.2에 있는 EllipseMorph 클래스 계층도를 다시 살펴보면, Morph 클래스와 EllipseMorph 클래스는 둘 다 defaultColor 를 구했음을 알 수 있습니다. Morph new openInWorld 로 새 Morph를 만들면 타원은 원래 노랑색이어야 하지만 파랑색으로 만들어지는걸 확인할 수 있죠.

이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정<sup>override</sup> 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.

가끔 서브클래스를 만들 때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주3">자식 클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은 경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 객체 지향 언어들처럼, 이 작업 역시 super send를 사용하면 가능합니다.

initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!

그러므로 하위클래스 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:

메서드 5.17: Super initialize
<syntaxhighlight lang="smalltalk">
BorderedMorph>>initialize
"initialize the state of the receiver"
super initialize.
self borderInitialize
</syntaxhighlight>

<center>{{HighlightDoubleBox|initialize 메서드는 항상 super initialize(상위 초기화)를 보내며 시작합니다.}}</center>

===self send 와 super send===

상속 받은 메서드의 동작을 재지정려면 super send 가 필요합니다. 그러나 상속 여부와 관계 없이 일반적으로 메서드를 구현하려면 self send 를 사용하면 됩니다.

self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.<ref name="역자주4">self와 super에 대한 내용은 [http://blog.naver.com/PostView.nhn?blogId=tkandrea92&logNo=80014873796&parentCategoryNo=2&viewDate=&currentPage=1&listtype=0&from=postList 이부분] 을 찾아보면 좀 더 자세히 알 수 있습니다.</ref>

super 자체는 상위 클래스를 나타내는것이 아니라는 것을 주의하세요! 사실 이렇게 오해할만 하기도 합니다. 또한 super 를 사용하면 수신자의 상위 클래스 내부에서 검색을 한다고 잘못 생각할 수도 있습니다.

임의의 모프로 보내질 수 있는 initString 메시지가 있다고 가정해보겠습니다:

<syntaxhighlight lang="smalltalk">
anEllipse initString ⇒ '(EllipseMorph newBounds: (0@0 corner: 50@40) color:
Color yellow) setBorderWidth: 1 borderColor: Color black'
</syntaxhighlight>

위의 경우 반환되는 값은 모프의 재생성 작업을 할 수 있는 문자열입니다. self와 super send의 조합을 이용한다면 어떻게 해야 정확한 결과를 얻을 수 있을까요? 먼저, 그림 5.3에 보이는 것 처럼, anEllipse initString 은 메서드 initString이 클래스 Morph에서 발견되도록 합니다.

[[image:initStringLookup.png|none|800px|thumb|그림 5.3: self 와 super sends]]

메서드 5.18: self send
<syntaxhighlight lang="smalltalk">
Morph>>initString
↑ String streamContents: [:s | self fullPrintOn: s]
</syntaxhighlight>

메서드 '''Morph>>initString''' 은 '''fullPrintOn: '''의 '''self send''' 를 수행합니다. 이 작업은 다시 원래의 수신자의 클래스인 EllipseMorph 클래스에서부터 두 번째 검색을 시작하게 하며 BorderedMorph 클래스에서 fullPrintOn: 를 찾게됩니다. (그림 5.3을 다시 보십시오)

여기서 대단히 중요한 점은, self send 가 사용되면 수신자 anEllipse 의 클래스인 EllipseMorph 클래스에서 메서드 찾기를 다시 시작하도록 만든다는 것입니다.

<center>{{HighlightDoubleBox|self send는 수신자의 클래스에서 동적 메서드 검색을 시작하게 합니다.}}</center>

메서드 5.19: super와 self send 의 조합
<syntaxhighlight lang="smalltalk">
BorderedMorph>>fullPrintOn: aStream
aStream nextPutAll: '('.
super fullPrintOn: aStream.
aStream nextPutAll: ') setBorderWidth: '; print: borderWidth;
nextPutAll: ' borderColor: ' , (self colorString: borderColor)
</syntaxhighlight>

super send 가 사용되었기 때문에, Morph 클래스에서 super send 가 실행된 클래스의 상위 클래스에서 메서드 검색을 시작합니다. 그 다음, Morph>>fullPrintOn:를 찾고 처리합니다.

super 에 의한 메서드 검색이 수신자의 상위 클래스에서 시작되지 않음에 주의합니다. 만약 상위 클래스에서 시작한다면 무한반복으로 수렴하는, BorderedMorph에서의 검색이 시작됩니다<ref name="역자주5">super send 가 호출된 메서드를 소유한 클래스의 상위클래스에서 메서드를 검색하기때문에 메서드 검색에 있어 무한루프에 빠지지 않는다는 의미</ref>.

<center>{{HighlightDoubleBox|super send는 super send를 실행하는 메서드를 가진 클래스의 상위 클래스에서 시작되는 정적 메서드 검색을 진행합니다.}}</center>

만약 당신이 super send 와 그림 5.3 에 있는 initString 의 탐색과정을 주의깊게 보셨다면, '''super'''의 바인딩은 정적이라는걸 아셨을 겁니다: 모든문제는 super send 가 들어있는 소스코드를 가진 클래스에 있습니다. 이런 super 와는 반대로 self의 바인딩은 동적입니다: self는 항상 현재 실생중인 메세지의 수신자를 의미하며 self로 전송된 모든 메세지들에 대한 메서드 검색은 수신자 클래스 자신부터 시작된다는 의미가 됩니다.

===이해할 수 없는 메시지===

원하는 메시지를 발견하지 못하면 어떤 일이 일어날까요?

메시지 foo를 anEllipse클래스에 보낸다고 가정하겠습니다. 첫번째로 일반적인 메서드 찾기 작업은 상속 관계를 따라 Object 클래스까지(또는 ProtoObject 클래스까지도) 이 메서드검색을 위해 이동됩니다. 메서드를 발견하면, 가상 머신은 객체에 self doesNotUnderstand: #foo 를 보냅니다. (그림 5.4를 봐주세요)

[[image:fooNotFound.png|none|800px|thumb|그림 5.4: 메시지 foo를 이해할 수 없습니다]]

이런 메서드 검색에 대한 반응동작은 완벽하게 일반적인, 동적 메시지 전송 이기 때문에, 메서드 검색은 클래스 EllipseMorph 클래스부터 다시 시작하지만, 이번에는 doesNotUnderstand: 라는 메서드를 검색합니다. 그리고 보이는 것처럼, 객체는 doesNotUnderstand: 메서드를 실행합니다: 이 메서드는 새로운 MessageNotUnderstood 객체를 만들고, 이렇게 만들어진 MessageNotUnderstood 객체는 현재의 진행 상황에서 디버거의 시작을 가능하게 합니다.

왜 이렇게 누가봐도 오류인 상황을 취급하기 위해 이 복잡한 처리과정을 거쳐야 할까요? 글쎄요, 이런 과정은 개발자에게 이런식으로 발생하는 오류를 가로채서 다른 작업을 할 수 있도록 해주는 쉬운 방법을 제공합니다. 대안을 원하는 경우, 모든 객체의 서브 클래스에서 메서드 "doesNotUnderstand" 를 쉽게 재지정하고, 오류를 취급할 수 있는 다른 방법을 제공할수도 있습니다.

사실, 이런 방법은 어떤 객체에서 다른 객체로 메시지 전달을 자동 위임 할 수 있도록 구현하는 쉬운 방법중 하나가 될 수 있습니다. Delegator 객체는 수신자 자신이 이해하지 못하는 모든 메시지를 처리할 책임이 있는 다른 객체에 넘기거나 자체적으로 오류를 발생시킵니다!

==Notes==
<references />

[[Category:SqueakByExample]]

Onionmixer: 주석번호 수정

2013-03-07T09:11:54Z

주석번호 수정

← Older revision		Revision as of 09:11, 7 March 2013
Line 101:		Line 101:
	이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정<sup>override</sup> 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.		이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정<sup>override</sup> 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.

	가끔 하위클래스를 만들때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="~~역자주2~~">자식클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)를 사용하면 가능합니다.		가끔 하위클래스를 만들때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주3">자식클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)를 사용하면 가능합니다.

	initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!		initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!
Line 125:		Line 125:
	상속 받은 메서드의 동작을 재지정려면 super send 가 필요합니다. 그러나 상속 여부와 관계 없이 일반적으로 메서드를 구현하려면 self send 를 사용하면 됩니다.		상속 받은 메서드의 동작을 재지정려면 super send 가 필요합니다. 그러나 상속 여부와 관계 없이 일반적으로 메서드를 구현하려면 self send 를 사용하면 됩니다.

	self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.<ref name="~~역자주3~~">self와 super에 대한 내용은 [http://blog.naver.com/PostView.nhn?blogId=tkandrea92&logNo=80014873796&parentCategoryNo=2&viewDate=&currentPage=1&listtype=0&from=postList 이부분] 을 찾아보면 좀 더 자세히 알 수 있습니다.</ref>		self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.<ref name="역자주4">self와 super에 대한 내용은 [http://blog.naver.com/PostView.nhn?blogId=tkandrea92&logNo=80014873796&parentCategoryNo=2&viewDate=&currentPage=1&listtype=0&from=postList 이부분] 을 찾아보면 좀 더 자세히 알 수 있습니다.</ref>

	super 자체는 상위 클래스를 나타내는것이 아니라는것을 주의하세요! 사실 이렇게 오해할만 하기도 합니다. 또한 super 를 사용하면 수신자의 상위 클래스 내부에서 검색을 한다고 잘못 생각할 수도 있습니다.		super 자체는 상위 클래스를 나타내는것이 아니라는것을 주의하세요! 사실 이렇게 오해할만 하기도 합니다. 또한 super 를 사용하면 수신자의 상위 클래스 내부에서 검색을 한다고 잘못 생각할 수도 있습니다.

Onionmixer: 번역수정

2013-03-07T08:48:59Z

번역수정

Show changes

Onionmixer: 번역수정

2013-03-07T07:13:43Z

번역수정

← Older revision		Revision as of 07:13, 7 March 2013
Line 123:		Line 123:
	===self sends 와 super sends===		===self sends 와 super sends===

	~~우리는 그렇지 않으면 재지정 될~~ 상속 동작을 ~~작성하기 위해 상위 발송이~~ 필요합니다. 메서드를 ~~작성하는 평상시의~~ 방법은~~, 상속된 메서드인지 그렇지 않던지 간에,~~ self ~~send를 사용하는 것입니다~~.		상속 받은 메서드의 동작을 재지정려면 \super \subind{super}{send}가 필요합니다. 그러나 상속 여부와 관계 없이 메서드를 구성하는 일반적인 방법은 self send 입니다.

	self send는 super send와 ~~어떻게 다를까요~~? ~~Self~~ 와 ~~같이 super는~~ 메시지의 ~~수신자를 표시합니다~~. ~~유일하게 변경된 것은 메서드 검색입니다~~. 수신자의 클래스에서 ~~검색을 시작하는 대신에~~, ~~super는~~ super ~~send가 발생하는 위치에서 메서드의 클래스의 상위 클래스 내부 에서~~ 시작합니다.		self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.

	Super가 상위 클래스가 아닌 것에 주의합시다! 이 오해는 일상적이고 자연스러운 것입니다. 또한 수신자의 상위 클래스 내부에서 검색을 시작한다고 생각하는 것 또한 흔한 실수 입니다.		Super가 상위 클래스가 아닌 것에 주의합시다! 이 오해는 일상적이고 자연스러운 것입니다. 또한 수신자의 상위 클래스 내부에서 검색을 시작한다고 생각하는 것 또한 흔한 실수 입니다.

	~~우리가~~ 모든 morph에 보낼 수 있는 메시지 initString을 ~~생각해 봅시다~~:		모든 morph에 보낼 수 있는 메시지 initString을 살펴보겠습니다:

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	anEllipse initString −→ '(EllipseMorph newBounds: (0@0 corner: 50@40) color:		anEllipse initString ⇒ '(EllipseMorph newBounds: (0@0 corner: 50@40) color:
	Color yellow) setBorderWidth: 1 borderColor: Color black'		Color yellow) setBorderWidth: 1 borderColor: Color black'
	</syntaxhighlight>		</syntaxhighlight>


	리턴 값은 morph를 다시 만들기 위해 처리할 수 있는 문자열입니다. 어떻게 이 문자열이 self와 super send의 조합을 통해 얻을 수 있는 결과와 정확히 같을 수 있을까요?		리턴 값은 morph를 다시 만들기 위해 처리할 수 있는 문자열입니다. 어떻게 이 문자열이 self와 super send의 조합을 통해 얻을 수 있는 결과와 정확히 같을 수 있을까요? 먼저, 그림 5.3에 보이는 것 처럼, anEllipse initString은 메서드 initString을 클래스 Morph에서 발견되도록 해줍니다.
	먼저, 그림 5.3에 보이는 것 처럼, anEllipse initString은 메서드 initString을 클래스 Morph에서 발견되도록 해줍니다.


	[[image:initStringLookup.png\|none\|800px\|thumb\|그림 5.3: self 와 super sends]]		[[image:initStringLookup.png\|none\|800px\|thumb\|그림 5.3: self 와 super sends]]
Line 146:		Line 144:
	메서드 5.18: self send		메서드 5.18: self send
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	~~Morph»initString~~		Morph>>initString
	↑ String streamContents: [:s \| self fullPrintOn: s]		↑ String streamContents: [:s \| self fullPrintOn: s]
	</syntaxhighlight>		</syntaxhighlight>


	메서드 '''~~Morph»initString~~''' 는 '''fullPrintOn: '''의 '''self send'''를 수행합니다. 이 작업은 클래스 EllipseMorph에서 두 번째 검색을 시작하여 fullPrintOn: in BorderedMorph를 찾습니다. (그림 5.3을 다시 보십시오)		메서드 '''Morph>>initString''' 는 '''fullPrintOn: '''의 '''self send'''를 수행합니다. 이 작업은 클래스 EllipseMorph에서 두 번째 검색을 시작하여 fullPrintOn: in BorderedMorph를 찾습니다. (그림 5.3을 다시 보십시오)

	반드시 기억해야 할 사실은 self send가 anEllipse의 클래스인 수신자 클래스에서 메서드 찾기를 다시 시작하도록 만든다는 사실입니다.		반드시 기억해야 할 사실은 self send가 anEllipse의 클래스인 수신자 클래스에서 메서드 찾기를 다시 시작하도록 만든다는 사실입니다.

Onionmixer: 번역수정

2013-03-07T06:34:32Z

번역수정

← Older revision		Revision as of 06:34, 7 March 2013
Line 55:		Line 55:


	===self ~~리턴하기~~===		===self 반환하기===

	EllipseMorph>>defaultColor (메서드 5.14)는 명쾌하게 Color yellow를 ~~리턴하지만~~, Morph>>openInWorld (메서드 5.15)는 ~~어떤 것도~~ 반환 하지 않음을 확인할 수 있습니다.		EllipseMorph>>defaultColor (메서드 5.14)는 명쾌하게 Color yellow를 반환하지만, Morph>>openInWorld (메서드 5.15)는 아무것도 반환 하지 않음을 확인할 수 있습니다.

	메서드 5.15: 상속된 메서드		메서드 5.15: 상속된 메서드

Onionmixer: 문서오류 수정

2013-03-07T06:33:51Z

문서오류 수정

← Older revision		Revision as of 06:33, 7 March 2013
Line 101:		Line 101:
	이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정<sup>override</sup> 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.		이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정<sup>override</sup> 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.

	가끔 하위클래스를 만들때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주2">자식클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</~~pre~~>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)를 사용하면 가능합니다.		가끔 하위클래스를 만들때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주2">자식클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)를 사용하면 가능합니다.

	initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!		initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!
Line 195:		Line 195:

	사실, 이 작업은 한 개의 오브젝트에서 다른 오브젝트로, 메시지의 자동 위임을 수행하는 쉬운 방법일 수 있습니다. 위임자 오브젝트는 단순히 자신이 이해하지 못하는 모든 메시지들을, 메시지들을 취급하는 책임을 담당하는 오브젝트에 위임하거나, 자체적으로 에러 메시지를 발생시켜버립니다.		사실, 이 작업은 한 개의 오브젝트에서 다른 오브젝트로, 메시지의 자동 위임을 수행하는 쉬운 방법일 수 있습니다. 위임자 오브젝트는 단순히 자신이 이해하지 못하는 모든 메시지들을, 메시지들을 취급하는 책임을 담당하는 오브젝트에 위임하거나, 자체적으로 에러 메시지를 발생시켜버립니다.


	==Notes==		==Notes==

Onionmixer: 번역수정

2013-03-07T06:32:46Z

번역수정

← Older revision		Revision as of 06:32, 7 March 2013
Line 97:		Line 97:
	===재지정과 확장 (Overriding and extension)===		===재지정과 확장 (Overriding and extension)===

	~~만약 우리가~~ 그림 5.2의 EllipseMorph 클래스 ~~계층도를~~ 다시 ~~본다면~~, ~~클래스 Morph와~~ EllipseMorph ~~모두 defaultColor을 실행한다는 것을~~ 알 수 있습니다. ~~사실, 만약 우리가 새로운 Morph(~~Morph new ~~openInworld)를 연다면, ellipse는 디폴트로 노랑색이 될 것이지만, 파랑 morph를 얻게 될 것입니다~~.		그림 5.2에 있는 EllipseMorph 클래스 계층도을 다시 살펴보면, Morph 클래스와 EllipseMorph 클래스는 둘 다 defaultColor 를 구했음을 알 수 있습니다. Morph new openInWorld 로 새 모프를 만들면 타원은 원래 노랑색이어야 하지만 파랑색으로 만들어지는걸 확인할 수 있죠.

	~~우리는 defaultColor메서드가~~ Morph로부터 ~~상속하도록 EllipseMorph가~~ defaultColor ~~메서드를 재지정하였다고 말할 수 있습니다.~~ 상속된 메서드는 anEllipse의 ~~관점에서 볼 때 더 이상 존재하는 것이 아닙니다~~.		이런경우를 defaultColor 메서드는 Morph로부터 상속받은 다음 EllipseMorph 가 재지정<sup>override</sup> 했다고 말합니다. defaultColor 의 경우처럼 상속된 메서드는, anEllipse의 관점에서는 더이상 존재하지 않는것이 됩니다.

	~~때때로, 우리는 상속된 메서드들을 재지정 하기를 원치 않으며, 몇 가지~~ 새로운 ~~기능으로 그 메서드들을 확장하기 원할 것입니다. 그 이유는 우리가 서브 클래스에서 지정하고 있는~~ 새로운 ~~기능 뿐만 아니라~~ 재지정된 ~~메서드를 불러올~~ 수 ~~있기를 원하기 때문입니다~~.		가끔 하위클래스를 만들때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주2">자식클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</pre>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)를 사용하면 가능합니다.
	스몰토크에서, 단일 상속을 지원하는 많은 오브젝트 지향 언어들처럼, 이 작업 역시 super send(상위 발송)~~의 도움으로 수행될 수 있습니다~~.

	~~이 메커니즘의 가장~~ 중요한 ~~어플리케이션은 initialize 메서드에 있습니다~~. 클래스의 ~~새로운 인스턴스가 초기화될 때마다~~, ~~모든 상속된~~ 인스턴스 변수를 ~~초기화하는~~ 것 ~~또한 매우~~ 중요합니다. ~~그럼에도 불구하고~~, ~~어떻게 이 작업을 해야 할 지에 관한 지식은~~ 상속 ~~사슬(the inheritance chain)에~~ 있는 ~~각 상위 클래스의 메서드들을 초기화 하는 기술에 정확히 담겨~~ 있습니다. ~~서브클래스는 심지어 상속된~~ 인스턴스 ~~변수 초기화를 시도할 때에도 아무런 역할을 하지 않습니다.~~		initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 상위 클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 하위클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!

	그러므로 ~~모든 더 많은 초기화 작업을 수행하기~~ 전에 super ~~initialize를 보내기 위해~~ initialize ~~메서드를 실행하는 것이~~ 좋은 ~~실행법 입니다~~:		그러므로 하위클래스 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:


	메서드 5.17: Super initialize		메서드 5.17: Super initialize
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	~~BorderedMorph»initialize~~		BorderedMorph>>initialize
	"initialize the state of the receiver"		"initialize the state of the receiver"
	super initialize.		super initialize.
Line 118:		Line 117:


	<center>{{HighlightDoubleBox\|~~Initialize~~ 메서드는 항상 super ~~Initialize~~(상위 초기화)를 보내며 시작합니다.}}</center>		<center>{{HighlightDoubleBox\|initialize 메서드는 항상 super initialize(상위 초기화)를 보내며 시작합니다.}}</center>



	===~~Self~~ sends 와 super sends===		===self sends 와 super sends===

	우리는 그렇지 않으면 재지정 될 상속 동작을 작성하기 위해 상위 발송이 필요합니다. 메서드를 작성하는 평상시의 방법은, 상속된 메서드인지 그렇지 않던지 간에, self send를 사용하는 것입니다.		우리는 그렇지 않으면 재지정 될 상속 동작을 작성하기 위해 상위 발송이 필요합니다. 메서드를 작성하는 평상시의 방법은, 상속된 메서드인지 그렇지 않던지 간에, self send를 사용하는 것입니다.

← Older revision		Revision as of 01:58, 17 September 2013
Line 5:		Line 5:
	과정은 꽤 단순합니다: 수신자의 클래스는 메시지를 처리하기 위해 클래스가 가진 메서드중 사용할것을 검색합니다. 만약 수신자 클래스에 메세지에 적합한 메서드가 없다면, 클래스는 상위클래스에 요청하고 찾을때까지 상속관계를 따라 클래스를 거슬러 올라갑니다. 메서드를 발견 했을 때, 메서드의 매개변수로 인자를 묶어 한덩이로 만들고 가상머신은 묶인것을 실행합니다.		과정은 꽤 단순합니다: 수신자의 클래스는 메시지를 처리하기 위해 클래스가 가진 메서드중 사용할것을 검색합니다. 만약 수신자 클래스에 메세지에 적합한 메서드가 없다면, 클래스는 상위클래스에 요청하고 찾을때까지 상속관계를 따라 클래스를 거슬러 올라갑니다. 메서드를 발견 했을 때, 메서드의 매개변수로 인자를 묶어 한덩이로 만들고 가상머신은 묶인것을 실행합니다.

	설명과는 ~~다르게~~ 과정이 그리 복잡하지는 않습니다. 하지만, 몇몇 질문들은 중요한점을 알려주고 있죠.		설명과는 달리, 과정이 그리 복잡하지는 않습니다. 하지만, 몇몇 질문들은 중요한점을 알려주고 있죠.

	* 메서드가 명확하게 값을 반환하지 못할때는 어떤 일이 일어나나요?		* 메서드가 명확하게 값을 반환하지 못할때는 어떤 일이 일어나나요?
	* 클래스가 ~~상위 클래스의~~ 메서드를 다시 구현하면 어떤 일이 일어나나요?		* 클래스가 super클래스의 메서드를 다시 구현하면 어떤 일이 일어나나요?
	* self와 super의 메시지 전송상 차이점은 무엇입니까?		* self와 super의 메시지 전송상 차이점은 무엇입니까?
	* 메서드를 찾지 못하면 어떤 일이 일어나나요?		* 메서드를 찾지 못하면 어떤 일이 일어나나요?
Line 49:		Line 49:


	반대로, 만약 메시지 openInWorld 를 Ellipse에 보낸다면, 이 메서드는 즉시 발견되지 않습니다, 그 이유는 클래스 EllipseMorph는 openInWorld를 구현하지 않았기 때문이죠. 그러므로 메서드 검색은, openInWorld 메서드를 클래스 Morph에서 발견할 때까지, ~~상위 클래스~~ BorderedMorph 그리고 다른 클래서에서도 계속됩니다. (그림 5.2를 보십시오)		반대로, 만약 메시지 openInWorld 를 Ellipse에 보낸다면, 이 메서드는 즉시 발견되지 않습니다, 그 이유는 클래스 EllipseMorph는 openInWorld를 구현하지 않았기 때문이죠. 그러므로 메서드 검색은, openInWorld 메서드를 클래스 Morph에서 발견할 때까지, super클래스 BorderedMorph 그리고 다른 클래서에서도 계속됩니다. (그림 5.2를 보십시오)

	[[image:openInWorldLookup.png\|none\|800px\|thumb\|그림5.2: 메서드 lookup 은 상속받은 상속관계를 따릅니다]]		[[image:openInWorldLookup.png\|none\|800px\|thumb\|그림5.2: 메서드 lookup 은 상속받은 상속관계를 따릅니다]]
Line 103:		Line 103:
	가끔 서브클래스를 만들 때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주3">자식 클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은 경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 객체 지향 언어들처럼, 이 작업 역시 super send를 사용하면 가능합니다.		가끔 서브클래스를 만들 때 상속받은 메서드를 재정의하는것이 아니라 원래있던 메서드의 기능에 새로운 기능을 덧붙이고 싶을때가 있습니다<ref name="역자주3">자식 클래스를 구현함에 있어 새로운 기능을 추가하면서 상속-재지정된 method 를 호출 할 수 있다는 말입니다.</ref>. 재지정된 메소드의 원래기능에 새로운 기능을 추가해서 사용하고 싶은 경우가 있기 때문이죠. 스몰토크에서, 단일 상속을 지원하는 많은 객체 지향 언어들처럼, 이 작업 역시 super send를 사용하면 가능합니다.

	initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 ~~상위 클래스에~~ 있는 initialize 메서드에 이미 작업되어 있습니다. 서브클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!		initialize 메서드는 이런 메커니즘에 있어서 대단히 중요한 예가 됩니다. 클래스의 새 인스턴스를 초기화 하는 때가 언제든지간에, 상속 인스턴스 변수를 초기화 하는 것 역시 대단히 중요합니다. 그러나, 이를 처리하는 방법에 대한 내용은 이미 상속 관계상 각각의 super클래스에 있는 initialize 메서드에 이미 작업되어 있습니다. 서브클래스는 상속 인스턴스 변수를 초기화 할 권리가 없습니다!

	그러므로 서브클래스 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:		그러므로 서브클래스 스스로의 initialize 를 진행하기 전에 super initialize 를 먼저 진행하는 것은 좋은 방법입니다:
Line 127:		Line 127:
	self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.<ref name="역자주4">self와 super에 대한 내용은 [http://blog.naver.com/PostView.nhn?blogId=tkandrea92&logNo=80014873796&parentCategoryNo=2&viewDate=&currentPage=1&listtype=0&from=postList 이부분] 을 찾아보면 좀 더 자세히 알 수 있습니다.</ref>		self send는 super send와 어떤 차이가 있을까요? self 와 super 는 둘 다 메시지의 수신자(자기 자신)를 의미합니다. 다른점이 있다면 메서드를 검색할때 뿐입니다. self 가 메시지를 받았을때 메서드의 검색을 수신자의 클래스에서 시작한다면, super 는 super send 가 발생된, 현재클래스의 상위클래스부터 검색을 시작합니다.<ref name="역자주4">self와 super에 대한 내용은 [http://blog.naver.com/PostView.nhn?blogId=tkandrea92&logNo=80014873796&parentCategoryNo=2&viewDate=&currentPage=1&listtype=0&from=postList 이부분] 을 찾아보면 좀 더 자세히 알 수 있습니다.</ref>

	super 자체는 ~~상위 클래스를~~ 나타내는것이 아니라는 것을 주의하세요! 사실 이렇게 오해할만 하기도 합니다. 또한 super 를 사용하면 수신자의 ~~상위 클래스~~ 내부에서 검색을 한다고 잘못 생각할 수도 있습니다.		super 자체는 super클래스를 나타내는것이 아니라는 것을 주의하세요! 사실 이렇게 오해할만 하기도 합니다. 또한 super 를 사용하면 수신자의 super클래스 내부에서 검색을 한다고 잘못 생각할 수도 있습니다.

	임의의 모프로 보내질 수 있는 initString 메시지가 있다고 가정해보겠습니다:		임의의 모프로 보내질 수 있는 initString 메시지가 있다고 가정해보겠습니다:
Line 167:		Line 167:


	super send 가 사용되었기 때문에, Morph 클래스에서 super send 가 실행된 클래스의 ~~상위 클래스에서~~ 메서드 검색을 시작합니다. 그 다음, Morph>>fullPrintOn:를 찾고 처리합니다.		super send 가 사용되었기 때문에, Morph 클래스에서 super send 가 실행된 클래스의 super클래스에서 메서드 검색을 시작합니다. 그 다음, Morph>>fullPrintOn:를 찾고 처리합니다.

	super 에 의한 메서드 검색이 수신자의 ~~상위 클래스에서~~ 시작되지 않음에 주의합니다. 만약 ~~상위 클래스에서~~ 시작한다면 무한반복으로 수렴하는, BorderedMorph에서의 검색이 시작됩니다<ref name="역자주5">super send 가 호출된 메서드를 소유한 클래스의 상위클래스에서 메서드를 검색하기때문에 메서드 검색에 있어 무한루프에 빠지지 않는다는 의미</ref>.		super 에 의한 메서드 검색이 수신자의 super클래스에서 시작되지 않음에 주의합니다. 만약 super클래스에서 시작한다면 무한반복으로 수렴하는, BorderedMorph에서의 검색이 시작됩니다<ref name="역자주5">super send 가 호출된 메서드를 소유한 클래스의 상위클래스에서 메서드를 검색하기때문에 메서드 검색에 있어 무한루프에 빠지지 않는다는 의미</ref>.


	<center>{{HighlightDoubleBox\|super send는 super send를 실행하는 메서드를 가진 클래스의 ~~상위 클래스에서~~ 시작되는 정적 메서드 검색을 진행합니다.}}</center>		<center>{{HighlightDoubleBox\|super send는 super send를 실행하는 메서드를 가진 클래스의 super클래스에서 시작되는 정적 메서드 검색을 진행합니다.}}</center>