카페에 가서 커피를 주문하는 경우를 생각해보면 다음과 같다.
손님 ---> 캐셔 ---> 바리스타
여기서 생각해야할 부분은 손님의 역할과 책임, 캐셔의 역할과 책임, 바리스타의 역할과 책임이다.
간단하게 카페에 가서 손님의 역할과 책임이면.. 손님은 케셔에게 주문을 하는 역할이고, 카페에서는 1인 1음료 주문을 해야하는 책임이 있다.
캐셔는 주문을 받고 바리스타에게 받은 주문을 알려준다. 그리고 정확하게 주문을 받아야하는 책임이 있다.
바리스타는 전달받은 주문을 제조하는 역할과 책임이 있다.
이 3사람은 커피 주문이라는 협력에 참여하고 있고 이 협력에 참여해 각자의 역할과 책임을 다 하고 있는 것이다.
이 이야기를 왜 하냐면, 바로 여기서 객체지향의 개념 3가지가 바로 역할, 책임, 협력이기 때문이다.
그럼 이어서 협력 이라는 말을 했는데 조금 더 자세하게 풀어보려고한다.
협력 = 요청 + 응답 이라고 생각하면 된다.
아까 주문 프로세스를 협력이라 했고 협력은 요청 + 응답이니 주문 프로세스를 요청과 응답으로 나눠보면 다음과 같다.
요청 : 손님 --(메뉴 주문)--> 캐셔 --(메뉴 제조)--> 바리스타
응답 : 손님 <--(메뉴 서빙)-- 캐셔 <--(메뉴 완성)-- 바리스타메뉴 주문, 메뉴 제조는 요청 / 메뉴 완성, 메뉴 서빙은 응답이 된다.
요청과 응답을 통한 인간의 협력은 더 크고 복잡한 문제를 해결할 수 있는 능력이나 공동체를 형성할 수 있다. 협력의 성공은 각 역할을 맡은 개인들이 요청을 얼마나 성실하게 수행했는가에 달려있다.
다음으로 역할과 책임에 대해 자세하게 이야기해보려고 한다.
위에서도 간단하게 정리했는데 다시 보면 각각이 역할을 맡게되면 어떠한 책임이 따르게 된다. 이처럼 역할이라는 단어는 책임의 의미도 내포하고 있다. 이처럼 어떤 역할을 맡고 그에 적합한 책임을 수행한다는 건 또 몇가지 중요한 개념들을 제시하게 된다.
- 여러 사람들이 동일한 역할 수행 가능, 대체도 가능
카페에 가면 캐셔는 혼자가 아니다. 1명일 수도 있지만 큰 매장인 경우엔 2명 이상인 경우가 존재한다. 손님은 마시고 싶은 커피만 제대로 주문이 된다면 어떤 캐셔에게 주문을 해도 상관없다. - 역할 수행 방법은 자율적으로 선택 가능
모든 바리스타들이 라떼아트를 할 떄 다 같은 모양으로 하지 않는다. 누구는 하트, 누구는 하트 2개, 누구는 잎모양 형태의 라떼아트를 한다. 이 처럼 바리스타들은 모두 단 하나 "커피 제조" 라는 요청에 대해서 각기 다른 방식으로 응답을 할 수 있다. => 다형성 - 여러 역할 수행 가능
큰 카페가 아니라 작은 카페인 경우 캐셔가 바리스타 역할도 같이하는 경우가 많다. 이 처럼 여러가지 역할 수행도 가능하다.
대충 여기까지 다 읽으면 현실의 커피 주문이 객체지향의 중요한 개념들을 포함하고 있다는 것을 눈치챘을 것이다.
사람 = 객체, 요청 = 메세지, 요청을 처리하는 법 = 메서드로 바꿔 생각하면 된다.
현실에서 사람들이 중요한 만큼 객체지향 세계에서도 객체들이 중요하다. 객체는 애플리케이션의 기능을 구현하기 위해 존재하게 되는데 커피 주문에서 처럼 객체들은 협력을 통해 기능을 구현하게 된다. 객체지향 애플리케이션의 아름다움을 결정하는 것이 협력이라 한다면 협력이 얼마나 조화를 이루는지를 결정하는 것은 객체라고 한다. 그럼 결국, 협력의 품질을 결정하는 건 객체의 품질이게 된다.
객체의 품질을 위해서라면 2가지 덕목을 갖춰야 한다고 한다.
-
객체는 협력적이어야 한다.
객체는 다른 객체의 요청에 충실하게 귀 기울이고 다른 객체에게 적극적으로 도움을 요청할 정도로 열린 마음을 지녀야한다. 객체는 응답하는 거지 어떤 방식으로 응답할지는 스스로 판단하고 결정하고 요청에 응할지에 대한 여부도 스스로 결정할 수 있다. -
객체는 자율적이어야 한다.
객체 스스로의 원칙에 따라 어떤 일을 하거나 스스로 통제해 절제하는 것을 의미한다.
2가지 덕목에서 보면 공통적으로 "스스로" 라는 단어가 나온다. 이 처럼 객체는 공동의 목표를 달성하기 위해 협력에 참여하지만 스스로의 결정과 판단에 따라 행동하는 자율적인 존재다. 바로 여기서 객체지향 설계의 묘미가 개방적인 동시에 충분히 자율적인 객체들의 공동체를 설계하는데 있다고 한다.
객체의 자율성은 내부와 외부를 명확하게 구분하는 점으로부터 나오는데 사적인 부분은 스스로 관리하고 외부에서 접근하지 못하게 해야하며 접근이 허락된 루트로만 접근 가능해야한다. 즉, 객체가 무엇을 수행하는 역할을 하는지에 대해서는 알 수 있지만 어떻게 수행하는지에 대해서는 알 수 없다.
오케이. 객체는 이제 어느정도 알겠는데.. 메세지랑, 메서드도 중요하다면서? 라는 생각을 갖는 분이 있을 것이다. 간단하게 정리하자면 메세지는 객체지향 세계에서의 의사소통 수단이고 "요청한다. 응답한다." 는 모두 "메세지를 송신한다. 메세지를 수신했다" 라고 바꿔 부를 수 있다. 메서드는 바로 메세지를 처리하는 방법으로 써 수신된 메세지를 객체만의 방법에 따라 처리하는 것을 의미한다.
모두 종합해보면 간략한 객체지향의 개념이 나타나게 된다.
- 객체지향 = 시스템을 객체로 분할해서 상호작용하는 자율적인 객체들의 공동체로 봄.
- 자율적인 객체는 안에 상태, 행위를 갖고 스스로 책임을 짐.
- 시스템의 행위(기능)을 구현하기 위해 다른 객체와 협력. 정해진 역할을 수행. 역할은 책임의 집합체.
- 협력을 위해 메세지를 전송하고 메세지를 처리하기 위해 적합한 메서드를 자율적으로 선택.
마지막으로, 훌륭한 객체지향 설계자가 되기 위한 첫번째 도전은 코드를 담는 클래스의 관점 -> 메세지를 주고받는 객체의 관점 으로 사고의 중심을 전환하는 것이다. 어떤 클래스가 필요한가? 가 아니라 어떤 객체들이 어떤 메세지를 주고받으며 협력하는가? 이다. 객체지향의 진짜 핵심은 클래스가 아니라, 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다.
객체지향은 클래스를 지향하는게 아니라 객체를 지향하는 것이라고 한다!!!
(그렇다고 절대 클래스가 중요하지 않다는 것은 아니라고 합니다.)
커피 주문하는 과정을 통해서 뭔가 쉽게 객체라는 것을 쉽게 설명? 정리? 해준 것 같아서 1장이라 그런지 집중이나 흥미유도가 좀 잘 된것 같다. 1장부터 조금 어려웠다면.. 살짝 힘들지 않았을까 싶다. 암튼 쉽고 이해하기 쉬운 설명과 함께 1장을 읽어보니 다음 장들도 기대되고 얼른 읽어보고 싶다는 생각이 들었다.
어떻게 보면 개발을 하면서 클래스를 사용해서 기반을 다지고 클래스로 인스턴스(객체)를 생성하다 보니깐 클래스가 설계도고 인스턴스가 결과물? 같은 느낌이 들어서 나도 모르게 클래스에 더 집중했었는데 1장을 통해서 그런 고정관념이 박살났다.
스타트가 중요하다고 생각하는데 이 책의 1장 스타트가 너무 좋았어서 얼른 나머지도 다 읽고 정리해보고 싶다.👍
