SqueakByExample:5.5
모든 것은 메시지 전송으로 이루어 집니다.
이 규칙은 스몰토크에서 프로그래밍의 본질을 꿰뚫습니다(essence).
절차상의 프로그래밍(procedural programming)에서, 실행해야 할 코드 조각의 선택은, 절차가 발신자(caller)를 사용하여 만들어 질 때 해야 합니다. 발신자는, 이름으로 정적으로 실행할 절차 또는 함수를 선택합니다.
객체 지향 프로그래밍에서, 우리는 “call methods”:(메시지 부르기)를 하지 않고, “Send message”(메시지 보내기)를 사용합니다. 용어의 선택은 중요합니다. 각 오브젝트는 그 자신의 책임을 갖고 있습니다. 우리는 몇몇 절차를 오브젝트에 적용함으로써, 오브젝트가 무엇을 해야 할지 말하지 않습니다. 그 대신에, 우리는 오브젝트에게 메시지를 발송함으로써, 우리를 위해 오브젝트가 어떤 일을 수행해줄 것을 공손하게 요청합니다. 메시지는 코드의 조각이 아닙니다: 메시지는 아무것도 아니고, 단지 이름과 인수의 목록입니다. 수신자(receiver)는 요청 받은 작업을 실행하기 위해 그 자체의 메소드를 선택하여 어떻게 응답해야 할지를 결정합니다. 동일한 메시지에 응답하기 위해, 다양한 오브젝트들은 아마도 다른 메소드들을 가질 수 있지만, 메시지를 수신하였을 때, 반드시 동적으로 메소드가 선택되어야 합니다.
3+4 | ⇒ 7 | "integer 3 에 인자 4 와 함께 메세지 + 를 보낸다" |
(1@2) + 4 | ⇒ 5@6 | "point (1@2) 에 인자 4 와 함께 메세지 + 를 보낸다" |
결론적으로, 우리는 동일한 메시지를 다양한 오브젝트들에 보낼 수 있으며, 각각의 오브젝트들은 메시지에 응답하기 위해 그 자신의 메소드를 가질 수 있을 것입니다. 우리는 +4 메시지에 응답하는 방법인, Smallinteger 3 또는 Point 1@2를 말하지 않습니다. 각각은, +를 사용할 자체 메소드를 갖고 있으며, 그 메소드를 사용하여 +4에 응답합니다.
메시지(message sends)에 기인한 스몰토크 모델의 결과들 중 한가지는, 너무나 많은 책임을 갖고 있는 것으로 추정되는 거대한 절차 메소드(procedural method)보다는, 다른 오브젝트들에 작업들을 위임하거나, 매우 작은 메소드들을 갖는 경향이 있는 오브젝트들이 소재한 위치에서, 하나의 형식을 권장한다는 것입니다.
Joseph Pelrine는 다음과 같이 이 원리를 간결하게 표현하였습니다:
다른 녀석에게 맞길 수 있는 일을 일부러 하지 마라
(객체가 처리할 수 있는걸 다른곳에 두지 마세요)
많은 오브젝트 지향 언어는 오브젝트를 위해 정적, 동적 연산을 제공하지만, 스몰토크에서는 오직 동적 메시지 보내기만 제공됩니다. 정적 클래스 연산(static class permeation)을 제공하는 대신에, 실제적으로, 클래스는 오브젝트이기에, 우리는 단순히 클래스에 메시지를 보내어 작업을 수행합니다.
스몰토크에서 거의 모든 작업은은 메시지 보내기로 이루어집니다. 하지만 소수의 몇 가지 행동은 반드시 취해야 합니다:
- 변수 공표(variable declaration)은 메시지 보내기가 아닙니다. 사실, 변수 공표는 심지어 실행 가능하지도 않습니다. 변수를 공표하는 것은 단지 공간을 다른 오브젝트 참조(object reference)에 위해 할당되도록 만드는 것입니다.
- 할당(Assignments)은 메시지 보내기가 아닙니다. 변수에 대한 할당은 변수 이름이 그 변수의 정의 범위 내에서 신선하게 묶이도록 합니다.
- 리턴은 메시지 보내기가 아닙니다. 리턴은 단순히 연산된 결과가 발신자(sender)에 리턴 되도록 만들 뿐입니다.
- 프리미티브(Primitives)는 메시지 보내기가 아닙니다. 프리미티브는 가상머신에서 실행됩니다.
이 약간의 예외들 외에, 거의 모든 작업은 메시지 보내기로 이루어집니다. 특별히, 스몰토크에서는 “공적 필드”가 존재하지 않기 때문에, 다른 오브젝트의 인스턴스 변수를 업데이트 하는 유일한 방법이란, 오브젝트에 메시지를 보내어 그 자신의 필드를 업데이트 하도록 요청하는 것 뿐입니다. 물론, 오브젝트의 모든 인스턴스 변수를 위해 setter와 getter 메소드를 제공하는 것은 좋은 오브젝트 지향 형식(object-oriented style)이 아닙니다. Joseph Perlrine 또한 이 내용을 매우 훌륭하게 표현하였습니다.