[객체지향의 사실과 오해] 1장 협력하는 객체들의 공동체, 2장 이상한 나라의 객체 (1일차)

소프티어 부트캠프를 하면서 멘토님이나 현직자 분들이 공통적으로 추천해준 책이라 읽어보고자 한다.

실제 코드가 없어서 "그래서 어떻게 적용시키라는 건데?" 라는 의문이 든다고 익히 알고 있다. 실제 서문에서도 비슷한 내용이 있고, 내용을 경험과 연결 짓기 위해 어느 정도의 지식이 필요하다고 한다. 다시 말해 결국 경험도 필요하다는 것이다.

실제 다회독 할 때마다 보이는 것이 많다고 하니 이번 기회에 1회독을 시작해보고자 한다.

1장. 협력하는 객체들의 공동체

• 객체지향이란?
  • 실세계를 소프트웨어로 구현하는 것이 객체 지향의 철학
  • 하지만 실제 소프트웨어 객체와 실세계 사물 간 연관성은 희미하다
  • 실세계를 모방하는 것이 아니라 새로운 세계를 창조하는 것
  • 생명체에 비유하는 이유는 캡슐화와 자율성을 설명하기 효과적이기 때문이다.
  • 현실에서는 암묵, 명시적 계약을 기반으로 협력한다. 즉, 메세지를 주고 받아 협력하는 객체와 유사하다.
• 카페테리아를 예시로 들어 설명한다.
  • 손님, 캐시어, 바리스타 간의 협력으로 카페테리아가 작동한다.
  • 즉, 역할이 존재하고 각 책임을 다한다.
  • 협력하는 객체들은 공동의 목표를 위해 역할과 책임들 다한다.
  • 여러 사람이 동일한 역할을 수행할 수 있다.
    • 손님은 커피만 받을 수 있다면 정확히 누가 역할을 수행하는 지 관심 없다. 그저 역할만 다하면 된다!
  • 역할은 대체 가능성을 의미한다.
    • 손님 입장에서 캐시어는 누구더라도 상관없기에 대체 가능하다.
  • 책임을 수행하는 방법은 자율적으로 선택할 수 있다.
    • 역할만 다한다면 저마다의 방식으로 처리해도 된다. 동일한 요청에 대해 다른 방식으로 응답할 수 있는 능력이 다형성이다.
  • 한 사람이 동시에 여러 역할을 수행할 수도 있다.
    • 캐시어와 바리스타를 한 사람이 동시에 수행할 수도 있다
• (사람, 요청, 방법) 은 (객체, 메시지, 메서드) 로 매핑할 수 있다.
• 객체지향 어플리케이션의 핵심은 협력이며, 협력은 객체를 통해 조화로움을 나타낸다.
  • 첫째, 객체는 충분히 협력적이어야 한다.
    • 전지전능하다면 내부 복잡도로 자멸한다.
    • 객체는 요청에 대해 응답할 뿐
  • 둘째, 객체는 충분히 자율적이어야 한다.
    • 객체 스스로 어떻게 응답할 지 결정해야한다.
• 객체가 협력하기 위해서는 행동과 그를 위한 상태를 함께 가지고 있어야한다.
• 객체의 자율성은 내외부를 명확히 구분하는 것으로부터 나온다.
  • 내부는 스스로 관리하고 차단
  • 외부는 허락된 수단을 통해서만 의사소통
• 결국 객체는 상태와 행위를 하나의 단위로 묶는 자율적인 존재
• 협력과 메시지
  • 객체는 오직 메시지를 통해서만 의사소통
• 메서드와 자율성
  • 객체가 수신된 메시지를 처리하는 방법이 메서드
  • 실행 시간에 메서드를 선택할 수 있다는 것이 OOP의 큰 특징
  • 메시지와 메서드의 분리는 자율성을 증진
  • 캡슐화 개념과 관련
• 객체지향의 본질
  • 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법
  • 자율적인 객체랑 상태와 행위를 지니며 스스로를 책임지는 객체
  • 객체는 목표를 위해 다른 객체와 협력한다. 협력 내에서는 정해진 역할과 책임을 다한다.
  • 협력을 위해 메시지를 사용하고 수신한 객체는 자율적으로 메서드를 선택한다.
• OOP 는 클래스 지향이 아닌 객체 지향임을 명시하자
  • 클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과

2장. 이상한 나라의 객체

• 앨리스의 키
  • 앨리스가 하는 행동에 따라 상태가 변했다.
  • 결과는 상태에 의존적이다.
• 객체는 상태, 행동, 식별자를 지닌다.
• 상태
  • 모든 일에서 어떤 행동의 결과는 과거 어떤 행동이 일어났었느냐에 의존한다.
  • 과거 행동의 이력을 통해 결과를 판단하기에는 어렵다.
  • 과거의 과정과 결과를 단순하게 기술하기 위해 상태라는 개념을 사용한다.
  • 모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다.
  • 이때 객체의 상태를 구성하는 모든 특징을 프로퍼티라 한다.
  • 프로퍼티는 정적이지만 프로퍼티의 값은 동적이다.
    • 객체 사이의 의미 있는 연결을 링크라 한다.
    • 객체를 구성하는 단순한 값은 속성이라 한다.
• 행동
  • 객체의 상태를 변경하는 것은 객체의 자발적 행동이다.
  • 객체의 행동이 상태를 변경한다는 것은 행동이 부수 효과를 일으킨다는 뜻이다.
  • 객체의 행동은 상태에 영향을 받으며 상태를 변경 시킨다.
    • 상호작용이 현재의 상태에 어떤 방식으로 의존하는 가?
    • 상호작용이 현재의 상태를 어떻게 변경시키는 가?
  • 객체는 다른 객체의 상태 변경도 유발할 수 있다.
    • 객체 자신의 상태 변경
    • 행동 내 협력하는 다른 객체에 대한 메시지 전송
  • 협력하는 객체는 메시지만 받기 때문에 해당 객체에서 어떤 일이 일어나는 지 알 수 없다. 이것이 캡슐화
  • 객체가 외부에 노출하는 것은 행동 뿐, 외부에서 객체에 접근할 수 있는 것도 행동 뿐
  • 메시지가 행동을 유발할 수 있지만 변경 여부는 객체 스스로 결정한다.
  • 캡슐화를 통해서 객체의 자율성을 높일 수 있다.
• 식별자
  • 객체를 서로 구분 가능한 프로퍼티를 식별자라 한다.
  • 객체와 값을 구분
  • 값
    • 상태를 이용해 값이 같은 지 판단할 수 있는 성질을 동등성
    • 값의 상태는 결코 변하지 않는다.
    • 오직 상태로만 동등성을 판단하기에 인스턴스를 구분하기 위한 별도의 식별자가 필요없다.
  • 객체
    • 시간에 따라 변경되는 상태를 포함한다.
    • 두 객체의 상태가 같더라도 시간에 따라 달라질 수 있으므로 독립된 별개의 객체로 다루어야한다.
    • 식별자를 통해 객체의 동일 여부를 판단할 수 있는 성질을 동일성이라 한다.
• 객체지향의 개발자들은 객체의 상태를 조회하고 상태를 변경한다.
  • 조회는 쿼리
  • 변경은 명령
  • 객체가 외부에 제공하는 행동의 대부분은 쿼리와 명령
• 행동이 상태를 결정한다
  • 상태를 먼저 결정하고 행동을 나중에 결정하는 방법의 단점
    • 상태를 먼저 결정할 경우 캡슐화가 저해된다.
    • 객체를 협력자가 아닌 섬으로 만든다.
    • 객체의 재사용성이 저하된다.
  • 행동에 초점을 맞춘다.
  • 행동이 상태를 결정한다!!
• 현실과 소프트웨어 객체의 가장 큰 차이??
  • 모방과 추상화라는 개념으로 두 관계를 설명하기에는 어렵다.
  • 모든 객체들은 능동적이므로 의인화하는 것이 포인트다. 
• 프로그램 객체는 현실의 은유