객체지향의 사실과 오해를 읽으며

개요

객체지향의 사실과 오해

나는 책을 사는 것을 좋아하는데, 특히 이 책은 항상 개발서적중에 상위권에 위치해있는 모습을 볼 수 있었다. 뿐만 아니라 인프런 강의를 들을 때 김영한강사님도 종종 책 제목을 거론하곤 해서, 개발공부를 시작할 때 사두었다. 사실 한번 읽어보긴 했었는데, 아무래도 시기상조였던 것인지 도통 무슨얘긴지도 잘 모르겠고 그냥 앨리스 얘기만 읽다가 그냥저냥 마무리했던걸로 기억한다.

어느덧 프로젝트 하나를 마무리해가는 지금, 어쩌면 책에서 좋은 내용을 찾을 수 있지 않을까 하여 다시한번 책을 읽어보며 인상깊은 내용들을 정리해보려 한다.

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

• 객체지향의 목표는 실세계를 모방하는 것이 아니라 오히려 새로운 세계를 창조하는 것이다.
  • 단순히 실세계의 비유가 객체지향의 다양한 측면을 이해하고 학습하는데 효과적이기 때문에 대응시키는 것이다.
• 객체지향의 중요한 개념: 역할, 책임, 협력
  • 객체는 역할과 그에 맞는 책임을 가지고, 서로 응답과 요청을 통해 협력한다.
• 객체는 협력적이며 자율적이어야 한다.
  • 객체는 요청에 응답할 뿐이지만 응답을 해야하는지, 한다면 어떤 방식으로 응답할지 스스로 판단하고 결정한다.

• 객체는 스스로 판단하고 결정하는 자율적인 존재로 남기 위해서, 필요한 행동과 상태를 함께 지녀야 한다.

• 객체의 사적인 부분은 스스로 관리하고 외부에서 접근할 수 없도록 해야하며, 객체의 외부에서는 접근이 허락된 수단을 통해서만 객체와 소통해야 한다.

• 객체지향의 세계에서는 메시지라는 한가지 의사소통수단만을 가진다.

• 객체는 다른 객체와 협력하기위해 메시지를 전송하는데, 다른 객체가 이러한 매시지를 받아 처리하는 방법을 메서드라 한다.

• 메시지와 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 매커니즘으로, 이것은 캡슐화개념과도 관련되어 있다.

• 객체지향의 가장 중요한 구성요소는 클래스가 아닌 객체임을 명심해야 한다.
  • 클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과하다.

2장 이상한 나라의 객체

• 객체는 상태, 행동, 식별자를 지닌다.

• 객체마다 과거에 발생한 행동의 이력을 통해 새로 발생한 행동의 결과를 판단하는 것은 너무 복잡하고 번거롭다 -> 상태만 알면 바로 행동의 결과를 쉽게 예측할 수 있다.
  • 객체의 상태를 구성하는 모든 특징을 통틀어 객체의 프로퍼티라고 한다. 이는 변경되지 않고 정적이다.
  • 프로퍼티 값은 언제나 변경될 수 있으므로 동적이다.
  • 프로퍼티는 다른 객체와의 의미있는 연결을 뜻하는 링크와 객체를 구성하는 단순값인 속성으로 구분할 수 있다.
• 객체의 행동으로 인해 발생하는 결과는 두가지 관점에서 설명할 수 있다.
  • 객체 자신의 상태 변경
  • 행동 내에서 협력하는 다른 객체에 대한 메시지 전송
  • 객체는 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동, 외부에서 객체에 접근할 수 있는 방법 또한 행동이다.
    • 결과적으로 객체의 자율성을 높인다.
• 모든 객체는 식별자를 가지며, 객체가 아닌 값은 식별자를 가지지 않는다.
  • 값은 숫자, 문자열, 날짜, 시간, 금액 등 변하지 않는 양이다.
    • 값의 상태는 보통 변하지 않으므로 불변상태를 가진다고 말한다.
    • 값의 상태가 같은지를 판단하는 성질을 동등성이라고 한다.
  • 객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다. 따라서 객체는 가변상태를 가진다고 말한다.
    • 상태가 완전히 같은 두 객체도 독립적인 별개의 객체로 다루어야 한다.
    • 식별자를 기반으로 객체가 같은지 판단할 수 있는 성질을 동일성이라고 한다.
    • 참조객체 또는 엔티티라고도 한다.

• 객체를 설계할 때, 행동을 먼저 결정하고 그에 맞는 상태를 부여해야 한다.

• 현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은, 현실과 달리 소프트웨어의 객체는 능동적이라는 것이다. 즉, 스스로 자신의 상태를 바꾼다.

3장 타입과 추상화

• 객체에 어떤 개념으 적용하는 것이 가능해서 개념 그룹의 일원이 될 때 객체를 그 개념의 인스턴스라고 한다.

• 개념은 객체들의 복잡성을 극복하기 위한 추상화 도구

• 데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터.
  • 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정
• 우리는 객체를 데이터 타입처럼 사용한다. 하지만 객체에서 중요한 것은 객체의 행동이므로 데이터로 보는 것은 옳지 않다.
  • 어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동이다.
  • 객체의 내부적인 표현은 외부로부터 철저하게 감춰진다.
• 두 객체가 서로다른 상태로 동일한 행동을 한다면 같은 타입 객체

• 두 객체가 같은 상태로 서로다른 행동을 한다면 다른 타입 객체

• 객체는 내부적으로 관리해야 하는 데이터가 아니라 객체가 외부에 제공해야 하는 행동을 먼저 생각해야 한다.
  • 데이터를 먼저 결정하고 객체의 책임을 결정하는 방법은 유연하지 못하다.
• 일반화/특수화는 행동에 관한 것이다.
  • 일반적인 타입은 특수한 타입에 비해 더 적은 수의 행동을 가진다.
  • 단, 특수한 타입은 일반적인 타입이 할 수 있는 모든 행동을 동일하게 수행할 수 있어야 한다.
• 일반화/특수화 : 슈퍼타입/서브타입
  • 서브타입은 슈퍼타입의 행위와 호환되기 떄문에 서브타입은 슈퍼타입을 대체할 수 있어야 한다.

• 타입은 추상화다. 타입을 이용하면 객체의 동적인 특성을 추상화할 수 있다.

• 객체지향 프로그래밍 언어에서 정적인 모델은 클래스를 이용해 구현된다. -> 클래스 != 타입
  • 클래스는 타입을 구현할 수 있는 여러 구현 매커니즘 중 하나일 뿐
  • 클래스와 타입을 구분하는 것은 설계를 유연하게 유지하기 위한 바탕이 된다.

4장 역할, 책임, 협력

• 객체지향의 세계에서는 어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다.

• 객체의 책임은 ‘객체가 무엇을 알고 있는가’ 와 ‘무엇을 할 수 있는가’ 로 구성된다.
  • 아는것
    • 개인적인 정보에 관해 아는 것
    • 관련된 객체에 대해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
  • 하는 것
    • 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
    • 다른 객체의 행동을 시작시키는 것
    • 다른 객체의 활동을 제어하고 조절하는 것
• 한 객체가 다른 객체에게 전송한 요청은 그 요청을 수신한 객체의 책임이 수행되게 한다. -> 메시지 전송
  • 즉 두 객체 간의 협력은 메시지를 통해 이루어진다.
• 역할의 개념을 사용하면 유사한 협력을 추상화해서 인지 과부하를 줄일 수 있다.
• 협력이 좀 더 유연해지며 다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.
  • 역할은 객체지향 설계의 단순성, 유연성, 재사용성을 뒷받침하는 핵심 개념이다.
• 책임-주도 설계 방법은 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 애플리케이션을 설계한다.
  • 시스템의 책임을 객체의 책임으로 변환하고, 각 객체가 책임을 수행하는 중에 필요한 정보나 서비스를 제공해줄 협력자를 찾아 해당 협력자에게 책임을 할당하는 순차적인 방식으로 객체들의 협력 공동체를 구축한다.
• 디자인 패턴은 전문가들이 반복적으로 사용하는 해결 방법을 성의해 놓은 설계 탬플릿의 모음, 이미 식별해 놓은 역할, 책임, 협력의 모음이다.
  • 책임-주도 설계의 결과를 표현한다.
• 테스트-주도 개발은 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해가는 방식이다.