객체 지향의 사실과 오해

0. 기억할 것

1. 객체지향에서 좋은 API 설계는 책임과 자율의 상충관계이다. what 보다는 how에 집중하라.
   How에 관한 내용을 파라미터로 넣으면 객체의 자율성이 떨어진다. How는 functional class로 만들어서 처리한다. 맴버 변수로 기억해야 한다.
2. 다른 object를 어떻게 호출할 것인가? 3가지가 있다. effective c++에서도 case3을 추천한다. 필요한 부분만 넘겨야 한다면 case2도 좋다.

class c1{
    ...
}
class c2{
    ...
}

// case1
class c1{
    c2 member_obj();
}
c1.member_obj.foo()

// case2
c1.call(c2,) // 이런식으로 코딩하면 좋지 않다. 객체 자체를 넘기면, 필요 없는 부분까지 c1에게 넘겨야한다.
c2.call(c1,)
c1.call(part_of_c2, ) // 이런 식이 좀더 났다. 

// case3 
foo(c1,c2,)

ps. Law of Demeter(최소 지식의 법칙)는 “서로 가까운 객체끼리만 통신하고, 불필요한 내부 구조는 알지 말라”고 한다. 
ps. ORB-SLAM에선 case1같이 순환참조 돼 있어 읽기 힘들다. 여러 객체가 책임감을 분산한다. (coupling 올라간다.)

1. 내용

객체 지향의 대한 오해부터 정리한다.

• 객체지향의 장점에 관한 오해
• 우리가 살고 있는 세계와 비슷하기 때문이다.
• 객체는 데이터를 갖고 행동도 할 수 있다. 사고의 과정과 비슷해서 좋은 것이다.

사실: 객체지향의 장점은 책임(구현), 역할(인터페이스), 협력(호출)을 나눠서 유지 보수가 쉬운 코드를 작성하는데 있다.

객체지향이 무엇인가?

• polymorphism (overloading, overriding), capsulization,
• 이것은 언어에서 제공하는 도구이고, 왜 쓰는지에 대해 배운다.

사실: 다형성은 수신자의 종류를 추상화 한다. 송신자 관점에서 동일한 역할을 수행하는 interface에 다른 msg넣어도 된다. 캡슐라이제이션은 냉부와 외부를 분리하여, 객체의 책임과 자율성을 늘린다,

2. OOP의 중요한 keyward

• 책에서 말하는 책임, 역할, 협력, 메세지
  책임: 객체 자체가 본인이 무엇을 할지 안다. 다른 객체를 어떻게 호출할지 안다. (책임감은 다른 객체가 해당 객체를 많이 알고 지낼수록 낮아진다.) 
  역할: 재사용 가능한 책임들의 집합 -> 인터페이스 역할을 한다.
  협력: 독립적이고 동적인 객체들간에 msg를 주고 받는다.
  메세지: obj.msg(arg), 수신자.해라(what을)
  설계 순서

1. 어떤 책임이 필요한지 식별하고, 해당 책임을 object에게 할 당한다.
2. 책임이 겹치면 역할로 (interface) 만든다.
3. 객체의 책임과 자율성을 보장하는 msg를 만든다. (제일 중요