[우테코 권장도서] 객체지향 사실과 오해 4장

4장 역할,책임,협력

역시 이책이 그렇듯 실제 예시를 들어가며 설명한다.

두명에 사람들에게 일정금액을 한명은 몇대몇으로 나눠가질지 한명은 받을지 말지 결정하고 기회는 단한번인 최후 통첩게임의 예시이다.

인간은 일단 돈을 아주 조금이라도 받으면 이득이기 때문에 아주 작은 비율이더라도 돈을 받을쪽으로 움직일것이고 비율을 결정하는자도 지가 많이 먹는 쪽으로 움직일것이라고 전통 경제학은 예상하지만 실제 결과는 그렇지 않다는것이다.

협상의 문맥상 사람들은 불합리하다고 생각이 들어 빡돌면 내가 돈을 받고 말고는 상관없고 그냥 손해보더라도 같이 손해보는 결과를 선택한다는 실험결과가 나온다는 것이다.

여기서 중요성은 문맥(context)이다 사람이 객체일텐데 객체는 문맥에 따라서 다른 행동을 할수도 있다는것이다.

일반적인 경제학관점에는 비율을 9:1 이런식으로 설정하고 돈을 무조건 받는쪽으로 행동하겠지만 협상(최후통첩게임)의 문맥상 사람(객체)는 그렇게 움직이지 않는다는것이다.

즉 객체를 설계할때도 문맥을 잘파악해야한다. -> 이런 문맥의 예시가 LSP의 오리예시에서 오리용도가 뭐냐에 따라 문맥에 맞을수도 안맞을수도 있다 이런 것들이 있다.

역할 책임 협력

협력

협력을 쭈루룩 이야기를 한다 근데 사실 이책에서는 거의 같다고 봐도 무방한 내용이 계속 중복되어서 나오기 때문에 그냥 내가 쭉읽고 정리되는 부분을 정리해볼까 한다.

이 책에서 말하는 협력은 context이자 최종적으로 도출해야하는 결과물일수도 혹은 그것의 부분집합일수도 있다.

객체지향은 프로그래밍을 하는 하나의 방법론이고 결국 프로그래밍은 어떤 상황을 프로그래밍적으로 풀어나가보라는 요구사항이다.

개발을 시작할때 이런 덩어리 요구사항이 나에게 최초로 해결하라고 떨어질것이다.

이것을 통으로 협력이라고 볼수있다. 이 협력을 부분적으로 쪼개서 작은 협력단위로 다룰수도 있을것이다.

어쩃든 이 협력상 적절한 문맥은 분명 존재할것이고(도메인상황에 맞아야 할것이다.)

이런 문맥을 고려해야 할것이다.

일단 협력을 하나의 말로 정리하자면 내가 해결해 나가야할 하나의 과제이다.

그리고 협력의 구성요소로 역할,책임,행동,상태(행동과 상태를 묶는다면 객체) 가 존재하는것이다.

역할 책임 등등 단위에 대한 생각

객지사를 읽다보면 역할 책임(상태 혹은 행동) 행동 상태 이렇게 쭈루루룩 나오는데 결국 행동(상태) 즉 객체가 뭘할수 있고 뭘 알고 뭘보여줄수 있는지에 대한 단위라고 생각한다. 그리고 결국 그 단계별로 추상화를 통해서 갈아끼울 수 있는 유연성을 보장하는것이라고 생각한다.

역할

역할은 책임(상태 혹은 행동) 을 묶어놓은 단위일 뿐이다 그리고 이를 추상화 시킨다면 객체지향의 특장점인 유연성과 재사용성을 높일수 있다.

그리고 역할의 단위로 묶어놓은 이유는 객체를 갈아끼울수있는 단위를 지정해준것이라고 생각한다.(즉 객체 상위 단위이다.)

그리고 이런 관점은 실제적으로 실생활과 대치해보면 설명하기 쉬운데 각각 어떤 행동을 취할수있는 사람을 역할이라는 단위로 바라보면 그 행동을 다 취할수 있는 보장하에 갈아끼울수 있다.

예를 들어 주방보조라는 역할에는 칼질이 필수적으로 요구되고 그렇다면 거기에 들어갈수있는 객체는 일식요리사든 중식요리사든 양식요리사든 상관없다. 그냥 맘대로 갈아 끼울수있는것이다. 이때 주방보조라는 추상화할수있는 단위가 있기 때문에 역할이 중요한것이다. 물론 어느 단위든 추상화 될수있지만 역할이야 말로 추상화를 크게 요하는 단위라고 생각한다.

책임

책에서 이번에 책임에 대해서 좀 자세히 세분화해서 설명한다.

책임에또한 행동 혹은 상태를 묶어놓은 단위라고 생각한다. 하지만 책임은 객체의 하위로 들어갈수있는 단위이다(객체 하위 단위이다.)

즉 객체는 책임을 들고있게 된다.

책임은 두가지 분류로 나눌수있다

하는것

• 객체를 생성하거나 계산을 하는 등의 스스로 하는것
• 다른 객체의 행동을 시작시키는것
• 다른객체의 활동을 제어하고 조절하는 것

아는것

• 개인적인 정보에 관해 아는것
• 관련된 객체에 관해 아는것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

거창해게 나눠놨지만 결국 상태를 외부에 제공하거나 다른 객체의 메시지를 던져서 참조할수있는 진입점을 갖거나

아님 우리가 계속해서 다뤘던 행동들이라는 것이다.

그래서 책임은 객체의 하위 단위로 어떠한 목적을 위한 행동과 상태를 묶어줄수 있는 단위라고 생각한다.

책임주도개발

이제 진짜 중요한 이야기하고 생각한다.

객체지향이라고 할때 객체라는 말에 빠져 작은 단위인 상태 행동 객체를 생각하고 그것을 협력으로 이끌어가려고 시도하는데 이는 참어렵다.

그래서 개발을 할때 애초에 크게 협력단위로 보고 그때 필요한 행동들을 쭉 정의하고 그다음 그 행동들을 묶어서 역할을 만들고 그 역할에 들어갈수 있는 책임을 가진 객체들을 설계해 나가는것이다. 각 책임과 역할들을 보며 어떤 객체가 들고있는것이 적절할까 계속 고민하는것이 객체를 설계해나가는 과정이 될것이다.

방금의 과정에서 객체의 세부 구현은 전혀 없었다. 이게 핵심이다.

뭔가 어디서 많이 본 프로세스 아닌가? -> 우테코에서 기능목록부터 작성하라는 과정을 쭉 따라가다보면 이 방법으로 설계해 나갈 수 있을것 같다.

이런과정을 다 거친다면 이제 객체가 가져야하는 행위의 목록들이 이미 정해져 있을것이고 그것들을 개발자가 자유롭게 구현해나가면 될것이다.

이런 방법으로 접근한다면 좀더 구성이 유연하고 객체에 적절한 책임들을 부여해 나갈수 있을것이다.

패턴

개똑똑한 선배 개발자들이 어떠한 협력(요구사항)에 맞는 역할과 책임을 미리 짜놓은 것이다.

그러니 패턴을 미리 공부좀 해놓는다면 자주 나오는 협력(요구사항)에 대응해 항상 설계를 할필요없이 좋은 방법을 통해 해결해 나갈수 있는것이다.

사실 설계 하는데 머리통이 터지는것이니 이것만 되있는것도 정말 꿀이라고 생각한다.

어쩃든 패턴은 역할과 책임만 쭉 나열되어있으니 객체는 어떻게 구현할지 나눌지는 사용자의 몫이다.

우리는 당연히 단위를 패턴책에서 제시한 UML대로 가야한다고 생각하지만

그냥 하나의 객체가 역할과 책임에 대응할수있게 짤수도 있는것이다.(물론 정말 별로지만)

결국 역할과 책임에 대해서 한번더 생각해보고 패턴을 사용해보면 좋을것같다.

TDD

기능목록을 짜고 그대로 TDD 프로세스를 진행하며 역할과 책임을 좀더 생각해보면 좋을것같다