내용 정리
서론
객체지향을 실세계의 모방으로 설명하는 것은 적합하지 않다. 하지만 많은 사람들이 이와 같은 방식을 채택하는 이유는 객체지향의 다양한 측면을 이해하고 학습하는데 매우 효과적이기 때문이다.
협력하는 사람들
직장인이 카페에 가서 아메리카노를 시킨다.
직장인은 캐시어에게 주문을 한다.
캐시어는 직장인으로부터 받은 정보를 컵에 적어 바리스타에게 넘긴다.
바리스타는 컵에 쓰여진대로 커피를 만든다.
바리스타가 완성된 음료를 캐시어에게 넘긴다.
캐시어는 진동벨을 울려 손님을 부른다.
손님은 진동벨을 반납하고 음료를 가져간다.
위 과정에서는 역할, 책임, 협력이라는 세가지 개념이 어울려 조화를 이루고 있다.
각 사람은 손님, 바리스타, 캐시어라는 역할을 가지고 있다.
각각은 협력하는 과정에서 자신이 맡은 책임을 다한다.
일상에서 발생하는 문제 중 본인이 해결하지 못하는 문제는 다른 사람에게 요청하며 해결한다. 일반적으로 다수의 사람들이 협력하기 때문에 이러한 요청은 연쇄적으로 일어난다.
요청을 받은 사람은 주어진 책임을 다하고 다른 사람의 요청에 응답한다. 응답 역시 연쇄적으로 발생한다.
사람들이 협력을 위해 특정한 역할을 맡고 이에 적합한 책임을 수행한다는 사실은 몇가지 중요한 개념을 제시한다.
여러 사람이 동일한 역할을 수행할 수 있다.
- 현재 바리스타 뿐만 아니라 다른 사람도 이 역할을 수행할 수 있다.
역할은 대체 가능성을 의미한다.
-두 사람이 같은 역할을 수행한다면 요청하는 사람 입장에서는 누가 해도 문제가 되지 않는다.
책임을 수행하는 방법은 자율적으로 선택할 수 있다.
- 커피를 만드는 방법은 다양하다. 이 중 어떤 방법을 사용할지는 바리스타의 선택에 달렸다.
한 사람이 동시에 여러 역할을 수행할 수 있다.
- 한 사람이 캐시어와 바리스타의 역할을 모두 할 수 있다.
역할, 책임, 협력
위에서 설명한 개념에서 사람이라는 단어를 객체로, 요청을 메세지로, 요청을 처리하는 방법을 메서드로 바꾸면 객체지향 문맥으로 옮겨올 수 있다.
객체도 인간과 유사하게 다른 객체와 적극적으로 협력한다.
객체는 다른 객체에게 도움을 요청하고 이런 과정이 연쇄적으로 일어난다.
객체는 분명한 책임이 있어야한다.
역할은 유연하고 재사용가능한 협력관계를 만들기 위한 중요한 요소이다.
협력 속에 사는 객체
객체지향 애플리케이션에서 역할, 책임, 협력이 중심이지만, 객체가 없으면 아무 소용이 없다.
객체지향 애플리케이션에서 아름다움을 결정하는 것이 협력이라면 협력이 얼마나 조화를 이루는지를 결정하는 것은 객체이다.
협력의 품질을 결정하는 것은 객체의 품질이다.
객체는 두가지 덕목을 가지고 있어야한다.
객체는 충분히 협력적이어야한다.
객체는 다른 객체의 요청에 귀 기울이고, 적극적으로 도움을 요청해야한다.
객체는 자율적이어야한다.
객체는 다른 객체의 요청에 따라 행동하지만, 자신의 행동을 스스로 판단하고 결정한다.
객체는 상태와 행동을 가지고 있다. 객체가 어떤 행동을 하려면 그에 필요한 상태를 가지고 있어야한다.
객체의 자율성은 외부와 내부를 구분하는 것에서 나온다. 다른 객체는 해당 객체가 무엇을 하는지는 알고 있어야 하지만, 어떻게 하는지는 알면 안된다.
객체가 자율적이어야 유지보수성이 증가한다.
객체는 다른 객체와 소통하기 위해서 메세지를 사용한다. 객체는 수신된 메세지를 처리하고 이 방식을 메서드라고 한다.
메세지를 수신한 객체가 실행시간에 메서드를 고를 수 있다는 것은 다른 언어와 객체지향언어를 구별하는 특성이다.
메세지와 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 기능이다. 이것을 캡슐화라고 한다.
객체지향의 본질
- 객체지향은 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할한다.'
- 자율적인 객체란 상태와 행위를 가지고 스스로 자기자신을 책임지는 객체이다.
- 객체는 다른 객체와 협력하고 협력 내에서 정해진 역할을 수행하고, 역할은 관련된 책임의 집합이다.
- 객체들은 협력하기 위해서 메세지를 주고받고, 각 객체는 이를 처리하기 위한 메서드를 스스로 결정한다.
객체지향을 보면 주로 클래스를 생각한다. 그런데 이것은 객체지향이라는 말이 전해져내려오면서 나타난 오류이다.
중요한 것은 어떤 클래스가 있느냐가 아니라 어떻게 객체가 메세지를 주고받는지이다.
클래스 구조가 아니라 역할, 협력, 책임에 집중하라
스터디
인상깊은 구절
책임이 불분명한 객체는 애플리케이션의 미래 역시 불투명하게 만든다.
이 구절을 읽고 내가 이제까지 만들었던 수많은 책임이 불분명한 객체들이 스쳐 지나갔다. 그 동안에는 객체지향을 잘 몰라서 객체의 책임에 대해서 생각을 깊게 하지 않았던 것 같은데, 이런 것들이 쌓이면 애플리케이션을 망친다는 것이 확 와닿았던 것 같다. 특히 팀프로젝트에서 이랬다면 팀원들이게 너무 미안했을 것 같다.
객체지향 애플리케이션에서 아름다움을 결정하는 것이 협력이라면 협력이 얼마나 조화를 이루는지를 결정하는 것은 객체이다.
책을 읽으면서 역할, 책임, 협력이 너무 연결되있는 느낌이라 느낌이 잘 안왔었는데 이 구절을 보고 조금 느낌이 온 것 같다.
질문과 토론
Q.어떤 메서드를 사용할지를 객체 스스로 정한다고 했는데, controller가 service에 요청하는 과정에서는 controller가 service의 메서드를 정한다. 그럼 이건 객체지향적으로 좋지 않은 코드인지?
인프콘에서 저자가 강연을 한 적이 있다. 여기서 저자는 객체지향적인 것은 도메인뿐이라고 하셨다고 했다. 생각해보면 controller가 클라이언트에게 받은 것을 service에 전달하고, service는 repository에 데이터를 저장하도록 한다. 그런데 이 과정이 모두 결정되어있고, 이는 객체지향적이라기보다는 절차지향적이라고 했다.
그러면 이렇게 배운 객체지향 개념은 어디다가 써야하는거지? 라는 생각이 들었다. 저 강연을 한번 봐야할 것 같다.
역할은 다형적 책임은 한가지이다.
협력은 메세지를 통해서 협력한다. -> 이것이 중요하다.
팩토리 객체를 생성하는 메서드를 빼두는게 객체를 위한 것이지 않나
책임중심방법론을 더 공부하자!
사이드프로젝트하면서 코드 고쳐보면서 읽으면 더욱 효과적일 것이다.
느낀점
사실 올해 초 이 책을 선배에게 추천받아서 읽어보았었다. 그 분이 이 책을 극찬을 하셔서 기대를 하고 읽었었는데, 막상 읽어보니까 무슨 말을 하려고 하는지 전혀 모르겠고 뭔가 빙빙 돌기만 하는 느낌이었다. 그런데 스프링을 배우고, 프로젝트를 해보고 읽으니 느낌이 많이 달랐다. 와 이걸 이렇게 표현하다니 감탄도 하고 내 코드들을 돌아볼 수 있는 시간이었던 것 같다. 빨리 다 읽고 오브젝트도 읽어보고싶다.
그리고 스터디를 하면서 정말 많은 이야기를 들었다. 확실히 나보다 더 큰 프로젝트를 하신 분들은 또 이 글을 읽는 관점이 다른 것 같았다. 첫 장이라 큰 내용이 없었는데도 이렇게 할 이야기가 많다니 신기했고, 앞으로가 기대된다!!
출처
객체지향의 사실과 오해 : 네이버 도서
네이버 도서 상세정보를 제공합니다.
search.shopping.naver.com
'객체지향 > 객체지향의 사실과 오해' 카테고리의 다른 글
| [객체지향 스터디] 2장 이상한 나라의 객체 (1) | 2024.09.24 |
|---|
