본 포스팅은 [객체지향의 사실과 오해] 책을 바탕으로 서술한 내용임을 밝힙니다.
객체지향의 사실과 오해 : 네이버 도서
네이버 도서 상세정보를 제공합니다.
search.shopping.naver.com
1장. 협력하는 객체들의 공동체
✔️ 협력하는 사람들
요청(request)
- 사람들은 스스로 해결하지 못하는 문제와 마주치면 문제 해결에 필요한 지식을 알고 있거나 서비스를 제공해 줄 수 있는 사람에게 도움을 요청한다.
- 한 사람에 대한 요청이 다른 사람에게도 요청을 유발하기 때문에 요청은 연쇄적으로 발생한다.
응답(respoense)
- 요청을 받은 사람은 주어진 책임을 다하면서 필요한 지식이나 서비스를 제공한다→다른 사람의 요청에 응답한다.
- 요청이 연이어 발생하기 때문에 응답 역시 요청의 방향과 반대 방향으로 연쇄적으로 전달된다.
- 협력(커피 주문)은 손님이 캐시어에게 원하는 커피를 주문하면서 시작된다. → 캐시어에게 커피 제공을 요청
- 주문을 받은 캐시어는 바리스타에게 주문된 커피를 제조해 줄 것을 요청한다.
- 바리스타는 커피 제조 완료됐음을 캐시어에게 알려준다. → 캐시어의 요청에 응답
- 캐시어는 진동벨을 울려 손님에게 커피가 준비됐음을 알린다. → 손님의 주문에 응답
카페테리아에서 손님이 주문한 커피를 제조하기 위해 캐시어와 바리스타가 협력하는 과정 속에서 '손님', '캐시어', '바리스타'라는 역할이 존재한다. 역할은 어떤 협력에 참여하는 특정한 사람이 협력 안에서 차지하는 책임이나 임무를 의미한다.
사람들이 협력을 위해 특정한 역할을 맡고 역할에 적합한 책임을 수행한다는 사실은 몇 가지 중요한 개념을 제시한다.
- 여러 사람이 동일한 역할을 수행할 수 있다. (손님 입장에서는 어떤 캐시어가 주문 받든 상관없다)
- 역할은 대체 가능성을 의미한다. → 손님 입장에서 캐시어는 대체 가능(substituable)하다.
- 책임을 수행하는 방법은 자율적으로 선택할 수 있다. → 동일한 요청에 대해 커피 향을 다르게 하거나, 라테 아트를 하는 등의 서로 다른 방식으로 응답할 수 있는 능력을 다형성(polymorphism)이라 한다.
- 한 사람이 동시에 여러 역할을 수행할 수 있다. (캐시어와 바리스타 역할을 동시에 수행해도 상관없다)
✔️ 역할, 책임, 협력
위의 커피 공화국의 예시에서, 사람→객체 / 요청→메시지 / 요청 처리 방법→메서드로 바꾸면 객체지향으로 이해할 수 있다.
시스템은 역할과 책임을 수행하는 객체로 분할되고 시스템의 기능은 객체 간의 연쇄적인 요청과 응답의 흐름으로 구성된 협력으로 구현된다. 객체 지향의 설계는 적절한 객체에게 적절한 책임을 할당하는 것에서 시작된다.
✔️ 협력 속에 사는 객체
객체지향을 객체지향이라고 부르는 이유는 패러다임의 중심에 객체가 있기 때문이다.
객체는 애플리케이션의 기능을 구현하기 위해 존재한다. 객체지향 애플리케이션의 아름다움을 결정하는 것이 협력이라면 협력이 얼마나 조화를 이루는지를 결정하는 것은 객체이다.
객체는 다음과 같은 두 가지 덕목을 갖춰야 한다.
- 객체는 충분히 '협력적'이어야 한다. 다른 객체의 명령에 따라 행동하는 수동적인 존재가 아니다. 그저 요청에 응답하는 것이다. 요청 응답 여부와 어떤 방식으로 응답할지는 객체 스스로 판단하고 결정한다.
cf. 외부의 도움을 무시한 채 모든 것을 스스로 처리하려는 전지전능한 객체(god object)는 내부의 복잡도에 의해 자멸하고 만다.
- 객체는 충분히 '자율적'이어야 한다. 객체 공동체에 속한 객체들은 공동 목표를 달성하기 위해 협력에 참여하지만 스스로의 결정과 판단에 따라 행동하는 자율적인 존재다.
객체의 자율성은 내부와 외부를 명확하게 구분하는 것으로부터 시작된다. 객체는 다른 객체가 '무엇(what)'을 수행하는지는 알 수 있지만 '어떻게(how)' 수행하는지에 대해서는 알 수 없다.
흔히 객체를 상태(state)와 행동(behavior)을 함께 지닌 실체라고 정의한다. 즉, 객체가 협력에 참여하는 과정 속에서 스스로 판단하고 스스로 결정하는 자율적인 존재로 남기 위해서는 필요한 행동과 상태를 함께 지니고 있어야 한다.
협력과 메세지
한 객체가 다른 객체에게 요청하는 것을 메시지를 전송한다고 말하고 다른 객체로부터 요청을 받는 것을 메시지를 수신한다고 말한다.
메세지를 전송하는 객체를 송신자(sender)라고 부르고 메세지를 수신하는 객체를 수신자(receiver)라고 부른다.
메서드와 자율성
객체가 수신된 메세지를 처리하는 방법을 메서드(method)라고 부른다. 메서드는 클래스 안에 포함된 함수 또는 프로시저를 통해 구현된다. 따라서 어떤 객체에게 메세지를 전송하면 결과적으로 메시지에 대응되는 특정한 메서드가 실행된다.
메시지와 메서드의 분리는 객체의 협력에 참여하는 객체들 간의 자율성을 증진시킨다. 이는 캡슐화(encapsulation)와 연관된다.
책을 읽으면서 아래의 내용이 이해가 잘 가지 않았다.
메시지를 수신한 객체가 실행 시간에 메세드를 선택할 수 있다는 점은 다른 프로그래밍 언어와 객체지향 프로그래밍 언어를 구분 짓는 핵심적인 특징 중 하나다. 이것은 프로시저 호출에 대한 실행 코드를 컴파일 시간에 결정하는 절차적인 언어와 확연히 구분되는 특징이다. (p. 34)
검색해 보니, 이 부분은 객체지향 프로그래밍(OOP)의 중요한 개념 중 하나인 다형성(polymorphism)을 설명하는 내용이었다. 이는 OOP에서는 “메시지를 받는 객체가 어떤 행동(메서드)을 실행할지 실행 시간에 결정할 수 있다”는 것이다. 이를 동적 바인딩(dynamic binding)이라고도 한다.
1. 절차적인 언어(Procedural language):
- C 같은 언어가 대표적
- 프로그램을 작성할 때, 함수나 프로시저가 호출될 때 어떤 코드가 실행될지 컴파일 시간에 결정된다. 즉, 코드를 작성할 때 이미 정해진 함수만 호출되고, 실행 중에 변경되지 않는다.
2. 객체지향 언어(Object-Oriented language):
- Java, Python, C++ 같은 언어가 해당
- 실행 시간(runtime)에 객체가 어떤 메서드를 실행할지 결정할 수 있다. 이 말은, 객체가 동일한 메시지(메서드 호출)를 받아도 어떤 객체가 그 메시지를 받느냐에 따라 실행되는 코드가 달라질 수 있다는 뜻이다.
✔️ 객체지향의 본질
- 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법이다.
- 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.
- 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
- 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메세지를 수신한 객체는 메세지를 처리하는 데 적합한 메서드를 자율적으로 선택한다.
객체지향의 핵심은 클래스가 아니다. 바로 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다.
즉, 객체지향의 중심에는 클래스가 아닌 객체가 위치하며, 중요한 것은 클래스들의 정적인 관계가 아니라 메세지를 주고받는 객체들의 동적인 관계이다.
객체지향에 대해 설명해 보아라 했을 때, 아직도 말하기엔 모호한 부분이 있었다. 뭔가 아는데 모르는 느낌이랄까?
이러한 이유로 '객체지향의 사실과 오해' 책 스터디에 참여하게 되었다.
Java Spring을 공부하겠다고 들은 강의에서 추상화 부분에서 왜 차와 차주로 비유했는지 마음에 와닿지는 않았었다.
이제는 왜 그렇게 비유를 했는지 이해할 수 있었다.
추가로 "메시지를 수신한 객체가 실행 시간에 메세드를 선택할 수 있다는 점은 다른 프로그래밍 언어와 객체지향 프로그래밍 언어를 구분 짓는 핵심적인 특징 중 하나다."는 부분에 대해 질문했는데, 스터디에서는 코드가 수행되는 중에 중간에 바리스타 1과 2가 변경될 수 있음으로 이해하면 쉽다고 말씀해 주셨다.
나는 거의 노베이스기 때문에, 기억할 만한 혹은 개념 위주로 블로그에 작성해 두었다. 다른 분은 책을 읽으면서 나의 마음을 찌르는, 곰곰이 생각할 만한 문구를 따로 작성하는 것이 좋다고 추천해 주셨다. 나중에 보기에도 편하고, 그 문장을 나의 언어로 바꾸기 수월하다고 말이다. 그래서 나는 1장에서는 역할, 책임, 협력은 두고두고 생각해 보기로 하였다.
스터디원이 책임과 역할을 구분 짓는 기준에 대해 질문하셨는데, 선뜻 대답하기 어려웠다. 책임이 모여 역할이 되는 것인지, 그러면 책임이 역할의 집합으로 들어가는 것인가 하고 명확하게 정의 내리기 어려웠다.
협력의 본질은 메시지를 통해 객체들이 상호작용하는 것이다. 책임과 역할의 구분 짓는 것은 오브젝트 책에 자세히 나와있는데, 다형적으로 처리할 수 있는 것은 역할이다. 객체지향의 사실과 오해 완독 후에 오브젝트 책 스터디도 시작해야겠다. 무척 어렵다고 하니, 객사오로 개념 탄탄히 잡고 가야지~🥵
추가로 MVC패턴에서 도메인 빼고는 다 절차지향적이다. 즉, 도메인만 객체지향적. 이 부분도 왜 그런지 생각하면 좋을 것 같다.
댓글