"객체는 실세계를 직접적이고 간접적으로 모델링할 수 있는 패러다임"은 잘못 되었습니다.
객체에 직접적으로 대응되는 사물은 그리 흔하지 않기 때문입니다.
소프트웨어 시스템이 해결하려고 하는 실재는 잘해봐야 먼친척밖에 되지 않는다. - Meyer
하지만 여전히 많은 사람들이 실세계 객체와 소프트웨어 객체간의 대응을 계속해서 표출시키는 이유는
객체지향의 다양한 측면을 학습하는데 매우 효과적이기 때문입니다.
스스로 결정하고, 스스로 생각하는 행위는 캡슐화와 자율성을 설명하는데 좋습니다.
현실 세계의 사람들이 암묵적인 약속과 명시적인 계약을 기반으로 협력하여 목표를 달성해 나가는 과정은,
메세지를 주고 받으며 협력하는 객체들의 관계를 설명하는데 좋습니다.
그래서 이번장에서는, 오해가 있더라고 전통적인 관점에서 객체지향의 다양한 개념을 설명하도록 하겠습니다.
식당에 들어서자 감질나는 냄새가 더 강해져서 기대감에 배가 꼬르륵거렸다. 그들은 아늑한 부스를 찾아 앉았고 신나게 메뉴를 스캔했습니다.
클래식 치즈버거부터 이국적인 미식가 조합에 이르기까지 선택의 폭은 무한해 보였습니다.
고심 끝에 철수는 바삭한 어니언 링과 녹은 치즈가 높이 쌓인 우뚝 솟은 버거를 선택했다.
그들은 간절히 주문을 하고 식사를 간절히 기다렸습니다.
마침내 그 순간이 왔습니다.
웨이트리스는 그들 앞에 아름답게 조립된 버거와 황금빛 감자튀김으로 장식된 두 개의 플래터를 놓았습니다.
햄버거는 예술 작품이었고 각 재료는 걸작을 만들기 위해 완벽하게 층을 이루었습니다.
여기서 철수는 손님의 역할로, 주문할 책임이 있습니다.
철수는 햄버거를 먹기위해 주문을 했고, 웨이트리스와 요리사의 협력을 통해 버거를 먹었습니다.
철수가 버거를 먹는 과정에서는 각 부여된 객체들의 협력과 역할, 책임이 존재하기 때문에 가능했습니다.
1. 요청과 응답으로 구성된 협력
철수는 버거를 먹는 손님의 역할이고, 버거를 주문하기위해 웨이트리스에게 도움을 구했습니다.
웨이트리스는 주문을 받았고, 요리사에게 버거를 만들어줄 도움을 구했습니다.
그리고 철수의 주문 요청의 응답으로 버거를 내놓았죠.
우리는 이것을 협력이라고 부릅니다.
손님, 웨이트리스, 요리사는 협력하는 과정에서 서로 역할을 부여받습니다.
역할을 협력에 참여하는 사람이, 협력안에서 차지하는 책임이나 의무를 의미합니다.
역할이라는 단어는 책임이라는 개념을 내포합니다.
손님은 무엇을 살 책임이 있고, 요리사는 어떤것을 요리할 책임을요.
역할과 책임은 협력의 핵심적인 구성 요소입니다.
- 여러사람이 동일한 역할을 수행할 수 있다(A요리사와 B요리사가 있지만, 햄버거만 나오면 OK)
- 역할은 대체가능성을 의미한다(동일한 역할을 수행한다면 문제가 되지 않는다)
- 책임을 수행하는 방법은 자율적으로 선택한다( 후라이팬으로 굽든, 전자레인지를 굽든...)
- 한사람이 동시에 여러 역할을 수행할 수 있다(웨이트리스가 요리사 업무를 동시에 수행 할수도 있습니다)
2. 기능을 구현하기 위해 협력하는 객체들
앞에 있는 철수와 웨이트리스, 요리사를 객체로, 요청을 메세지로 처리하는 방법을 메서드로 바꾸면
객체지향을 좀더 이해하기가 쉽습니다.
다만 사람들과 다른점이 있습니다.
공통의 목적을 달성하기 위해 서로 협력하지만, 객체들은 어플리케이션의 기능을 구현하기 위해 협력한다는 점이죠.
3. 협력속에 사는 객체
협력, 책임, 역할을 얘기했지만 결국 중요한것은 협력에 참여하는 객체이고, 객체는 어플리케이션의 기능을 구현하기 위해 존재합니다.
아주 작은 기능조차 객체 혼자 감당하기 버겁기 때문에, 협력을 통해 기능을 구현합니다.
하지만 협력이 얼마나 조화를 이루는지 결정하는것은 객체입니다.
- 객체는 충분히 협력적이어야 한다.(지혼자 다하는 객체는.. 문제가 많겠죠?
- 객체는 충분히 자율적이어야 한다.(요청에 응답할지, 어떤 방식으로 응답할지는 객체 스스로 판단합니다)
4. 상태와 행동을 함께 지닌 자율적인 객체
객체가 스스로 판단하고, 결정하는 자율적인 존재로 남기 위해서는 행동과 상태를 함께 지니고 있어야 합니다.
또한 중요한건 객체의 사적인 부분은 객체 스스로 관리하고, 접근이 허락된 수단을 통해서만 객체와 의사소통을 해야합니다.
객체지향에서는 데이터(상태)와 프로세스(행동)을 객체라는 틀로 하나로 묶음으로써, 유지보수가 쉬워졌습니다.
5. 협력과 메세지
사람과 사람관계에서 누군가에게 도움을 요청할때 여러가지 의사소통의 수단이 있지만,
객체에서는 메시지 하나입니다.
보내는 사람을 송신자, 받는 사람을 수신자라고 부릅니다.
6. 메서드와 자율성
객체는 메시지를 이해할 수 있는지 판단하고, 메세지를 처리합니다.
언어에서는 클래스안에 포함된 함수를 통해 실행이 되는것입니다.
메세지를 처리하기 위한 방법인 메서드 분리(캡슐화)는 객체의 자율성을 높이는 핵심입니다.
컴파일 시간에 결정하는 절차적인 언어와 완전 다르죠?
7. 객체지향의 본질
객체는 클래스가 아닙니다.
클래스는 객체를 만드는데 필요한 구현 메커니즘일 뿐입니다.
훌륭한 객체지향 설계자가 거쳐야할 첫 번째 도전은, 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고를 전환하는 것입니다.
어떤 클래스가 필요할까?가 아니라 어떤 객체들이 어떤 메시지를 주고 받으며 협력하는가를 중요시하세요.
클래스의 구조와 메서드가 아닌, 객체의 역할, 책임, 협력에 대해 집중하세요.
참고
