IT 책 독서록

[객체지향의 사실과 오해] 5장 내용정리

robinjoon98 2022. 3. 1. 23:37

2021.07.29 - [IT 책 독서록] - [객체지향의 사실과 오해] 4장 내용정리

 

[객체지향의 사실과 오해] 4장 내용정리

2021.07.20 - [IT 책 독서록] - [객체지향의 사실과 오해] 3장 내용정리 [객체지향의 사실과 오해] 3장 내용정리 2021.07.14 - [IT 책 독서록] - [객체지향의 사실과 오해] 2장 내용 정리 [객체지향의 사실과

blog.robinjoon.space

4장에서 개별 객체가 아니라 협력의 관점에서 바라보라고 한다. 5장에선 이 협력을 위해서 책임을 정의하는데, 이 과정에서 책임을 어떻게 정해야 하는지, 그 책임을 어떤 객체에게 어떻게 부여 할 것인지 등을 다룬다.

역할과 책임은 분명해야 한다.

책의 본문에선 1964년에 진행된 어떤 심리학 실험을 인용하며 협력에서 역할과 책임이 흐릿하면 안된다고 말한다. 현실에서도 어떤 일을 수행할 책임이 분명하지 않다면 문제가 생기고 나아가 협력 전체가 깨져버린다. 마찬가지로 객체지향 세계에서도 역할과 책임은 명확해야 한다.

책임은 자율적이여야 한다.

객체의 책임은 협력의 의도를 명확히 표현할 수 있는 정도로만 추상적이여야 한다. 1 ~ 4장에서 말하는 대로 객체는 자신에게 주어진 책임을 수행할 방법을 스스로 정할 수 있어야 한다. 그러기 위해서는 애초에 책임이 어느정도 추상적이여야 한다. "증언하라" 여야 하지, "기억에 의존하여 서면으로 증언하라"여서는 안된다. 하지만, 너무 추상적 이여서 협력의 의도를 표현할 수 없다면 안된다. 명확하지 않기 때문이다. "말해라"가 아니라 "증언하라" 여야 한다.

책임은 객체가 "어떻게(How)"가 아니라 무엇(What)"을 해야하는지 를 설명해야 한다. 

메시지와 메서드

객체는 스스로 책임의 수행을 시작하지 않는다. 다른 객체로부터 요청을 받아야 책임을 수행하기 시작한다. 이 요청을 메시지라고 한다. 객체는 메시지를 받으면, 이 메시지를 자신이 수행할 수 있는지 판단하고, 메시지에 대응되는 책임을 어떻게 수행할 것인지 스스로 정해 책임을 수행한다. 이 때 책임을 수행하는 방법을 메서드라고 한다. 

 

메시지는 메시지의 식별자인 메시지 이름과 추가정보인 인자로 이루어진다. "증언하라" 는 메시지 이름이고, "왕궁","어제" 는 인자다. 객체는 메시지 이름과 인자를 조합하여 해석하여 수행할 것인지 판단한다.

 

메시지는 공개되어있다. 1 ~ 4장에서, 객체는 스스로 판단하여 책임을 수행한다고 했다. 스스로 판단하기 위해서는 책임을 수행하는 방법인 메서드는 공개되면 안된다. 즉, 메시지는 공개된 영역이고, 메서드는 감춰진 영역이다. 즉, 메시지는 객체가 다른 객체와 소통하는 유일한 수단이며, 메시지를 어떻게 처리하는지는 메시지를 받은 객체만 알고 있다.  

 

인터페이스 : 객체끼리 상호작용하기 위한 장치. 즉 메시지의 목록이다. 인터페이스는 두가지로 나뉜다.

  1. 공용 인터페이스 : 외부에 공개되어 다른 객체와의 소통을 위한 메시지의 목록이다.
  2. 사적 인터페이스 : 외부로부터 감춰져 자기 자신과의 소통을 위한 메세지의 목록이다.

객체는 자기 자신과 소통할 때에도 메시지를 이용한다.

 

다형성 : 서로 다른 유형의 객체동일한 메시지에 대해 서로 다르게 반응하는 것을 말한다.

 

서로 다른 객체들이 다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것을 의미한다. 즉, 대체 가능성을 의미한다. 

 

다형성을 사용하면 같은 메시지를 처리하는 객체가 여럿이 존재하게 되고, 이는 객체와 객체간의 결합을 메시지에 대한 결합도로 낮추게 된다. 즉, 메시지를 송신하는 객체의 변경없이 수신받는 객체만 변경하여 메시지를 처리하는 방식을 바꿀 수 있게 된다. 이는 유연하고 재사용가능하고 확장 가능한 구조를 만들 수 있게 해준다.

 

객체 자체에 초점을 잡고 설계를 하면 안되고, 협력이라는 문맥안에서 생각해야 한다. 객체 자체의 상태와 행위가 아니라, 협력을 위해 객체가 다른 객체에게 제공해야 하는 메시지에 대해 고민해야 한다.

협력이 아닌 객체 자체에 초점을 맞추게 되면 협력이라는 문맥을 배제한 체 객체 내부의 데이터구조를 먼저생각한 후 객체의 행동을 나중에 고려하게 된다. 이는 곧 객체 내부의 데이터를 객체의 정의에 포함시켜 객체의 자율성을 떨어트린다. 따라서 객체를 독립된 단위가 아니라 협력이라는 문맥 안에서 생각해야 한다.

객체가 다른 객체에게 제공해야 하는 메시지에 대해 고민해야 한다.

 

What/Who 사이클

객체를 먼저 결정하는 것이 아니라, 객체가 어떤 행위(What)를 할지 먼저 결정한 후 어떤 객체(Who)가 그 행위를 수행할지 결정해야 한다. 

즉, 협력이라는 문맥안에서 필요한 메시지를 먼저 결정하고 메시지를 수신하기에 적합한 객체를 찾는다. 

객체가 "어떤 메시지를 수신하고 처리할 수 있는가" 가 책임을 결정하기 때문에 협력에 필요한 메시지를 먼저 찾고 이를 적절한 객체에 할당하여 객체의 인터페이스를 완성시켜야 한다.

 

데메테르 법칙

메시지를 먼저 정하고 나중에 객체를 정한다. 즉, 메시지를 정하는 시점에선 객체가 정해지지 않았으니, 객체의 상태 자체를 논할 수 없다. 결국 메시지를 먼저 정하고 나중에 객체를 정함으로써 객체의 캡슐화를 증진시킬 수 있고 이는 곧 자율적인 객체를 탄생시키며 객체들간의 결합도를 느슨하게 만든다.

객체는 다른 객체의 상태를 묻지 말아야 한다. 객체가 다른 객체의 상태를 묻는다는 것은 데메테르 법칙(묻지말고 시켜라)를 정면으로 위반하는 것이다. 묻지 말고 시켜라 라느 것은 메시지가 어떻게 해야하는지 지시하는것이 아니라 무엇을 해야하는지 요청 하는 것이다.

 

책임 주도 설계와 What/Who 원칙

메시지는 책임을 수행하기 위한 방아쇠다. 따라서 메시지를 결정한다는 것은 곧 책임을 결정한다는 것이다.메시지를 먼저 결정하고 객체를 선택한다는 것은 책임을 먼저 정하고 이를 적절한 객체에 할당한다는 말이 된다. 이는 결국 책임 주도 설계를 말한다. 

인터페이스와 구현의 분리

구현이란 객체의 내부의 구조와 작동방식을 가리키는 말이다.

인터페이스와 구현의 분리는 결국 내부와 외부를 분리하여 내부는 외부로부터 감추라는 말이다. 즉 인터페이스와 구현의 분리는 캡슐화다. 이는 곧 객체를 자율적으로 만든다. 

 

변경에 유리한 협력은 자율적인 책임에서 나온다.

변경에 유리한 협력을 만드는 것이 좋은 것이다. 그리고, 객체의 책임이 자율적일수록 협력이 변경에 유연해진다.

그 이유는 다음과 같다.

  1. 자율적인 책임협력을 단순하게 만든다.
  2. 자율적인 책임객체의 내부와 외부를 명확히 분리한다.
  3. 자율적인 책임책임을 수행하는 내부적인 방법의 변경이 외부에 영향을 미치지 않는다.
  4. 자율적인 책임협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
  5. 자율적인 책임객체의 역할을 이해하기 쉽게 해준다.