책리뷰 - 객체지향의 사실과 오해(+ 요약)

 

자바 백엔드 개발자로 실무를 하다보면 객체지향에 대한 이야기를 가끔 듣게된다. 

사실 변명이지만, 업무를 할때는 일정에 쫒겨 원칙이나 개념적인 것 보다는 구현에 더 집중할 수 밖에 없다. 그래서 객체지향을 자주 듣고 개념관련된 내용도 알고 있지만 자신있게 다른 사람에게 설명할 수 없는 정도의 지식을 가지고 있었던 것 같다. 근래에 서비스 설계를 하면서 좋은 설계에 대한 고민을 하다보니 근본적인 객체지향에 대한 궁금증이 생겼다.

 

나와 비슷한 고민을 가지고 있는 개발자들을 위해 객체 지향 관련한 서적 중 유명한 책인 '객체지향의 사실과 오해'를 읽고 서평을 써보고자 한다.

 

객체지향이라 하면 다들 Object-Oriented Programing (OOP)를 가장 많이 들어 봤을 것이다. 특히, 면접을 준비하는 경우 필수적으로 객체지향과 핵심 개념인 추상화, 상속, 다형성, 캡슐화 등에 대해서 개념을 공부하게 된다. 처음 이 책을 읽기 전에 이런 개념들에 대한 대다수의 원론서 같은 형태로 정리되어 있을 것이라고 생각했다. 하지만 이 책은 개념이 정리되어 있는 개념서라기 보다는 최대한 쉽게 핵심을 이해할 수 있게 하기 위한 예시글 같은 느낌이었다. 일반적인 개발 서적과는 아주 다른 느낌의 문과적인 느낌의 책이라고 하면 적당하려나!

 

해당 책을 읽어보면 개념적으로 필요에 의해 외우듯이 알고 있던 객체지향의 개념을 제대로 이해하게 될 것이라 감히 말할 수 있다. 객체지향에 대해 궁금하다면 꼭 읽어보는 것을 추천한다.

 

책의 저자인 조영호님의 강의도 들어봤지만, 강의보다도 책의 글이 참 맛있게 쓰여 있어서 시간이 지나고 다시 읽어보게 될 것 같다.

 

 

 

아래 대략적인 목차와 각 장별 핵심을 정리했으니, 책을 읽어보고 싶은 분들이라면 참고해 보시면 좋을 것 같다.

 

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

커피숍을 예시로 손님, 캐셔, 바리스타의 책임과 역할을 기준으로 객체지향에 대해 이해 할 수 있도록 설명되어 있는 장

 

• 객체 지향에서 중요한 개념 3가지
  • 역할
  • 책임
  • 협력

• 책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소
• 객체 역할의 특징
  • 여러 객체가 동일한 역할을 수행할 수 이음
  • 역할은 대체 가능을 의미
  • 각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있음
  • 하나의 객체가 동시에 여러 역할을 수행할 수 있음
• 협력에 참여하는 주체는 객체
• 객체는 상태(state)와 행동(behavior)을 함께 지닌 실체

 

• 객체 지향의 본질
  • 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이요해 시스템을 분할하는 방법
  • 자율적인 객체는 상태와 행위를 함께 지님
  • 객체는 시스템 구현을 위해 다른 객체와 협력, 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합
  • 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택

---

2장. 이상한 나라의 객체

객체를 이상한 나라의 앨리스라는 동화에 비유하여 설명, 해당 설명을 보다보면 객체와 객체지향에 대한 개념이 자연스럽게 이해 됨

 

• 객체는 상태, 행동, 식별자를 지닌 실체
  
  • 상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현
    • 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성
  • 행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동
    • 객체의 행동은 상태에 영향을 받으며, 상태를 변경 시킴
  • 식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티
    • 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교할 수 있음

 

---

3장. 타입과 추상화

영국 런던의 지하철과 이상한 나라의 앨리스의 트럼프 인간들을 예시로 추상화에 대한 개념을 설명

 

• 추상화
  • 어떤 양상, 세부 사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춰서 복잡도를 극복하는 방법
  • 그룹으로 나누어 단순화
  • 분류는 추상화를 위한 도구
• 타입
  • 타입은 개념과 동일
  • 객체를 분류하기 위해 사용하는 개념
  • 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미
• 객체지향 프로그래밍 언어에서 정적인 모델은 클래스를 이용해 구현
  • 타입을 구현한느 가장 보편적인 방법은 클래스를 이용하는 것
  • 참고) 클래스와 타입은 동일하지 않음!

---

4장. 역할, 책임, 협력

객체의 역할과 책임, 협력에 대해 이상한 나라의 앨리스 속 한 장면인 재판 장면을 예시로 설명

• 객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고 어떤 객체로부터 메시지를 수신할 것인지를 결정한느 것으로부터 시작됨

 

•  협력
  • 할당된 업무나 일을 처리하던 중 다른 객체에 요청이 필요한 부분은 요청을 하고 응답을 받는 것
• 책임
  • 어떤 객체가 요청에 대한 응답할 수 있거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 함
  • 객체의 책임은 하는것과 아는 것으로 분류 가능
• 역할 role
  • 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시
  • 역할의 가장 큰 가치는 하나의 협력 안에 여러 종류의 객체가 참여할 수 있게 함으로써 협력을 추상화 할 수 있다는 것
• 객체 지향 설계 기법
  • 책임-주도 설계(Responsibility-Driven-Design)
    • 설계
      • 기능 구현을 위한 협력 관계 고안
      • 협력에 필요한 역할과 책임을 식별
      • 이를 수행할 수 있는 적절한 객체를 식별해 나가는 과정
    • 핵심
      • 올바른 책임을 올바른 객체에게 할당하는 것
  • 디자인 패턴
    • 책임-주도 설계의 결과를 표현
    • 패턴은 모범이 되는 설계
    • 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿
  • 테스트 주도 개발 Test-Driven-Development 
    • 테스트 주도 개발의 기본 흐름
      • 실패하는 테스트 작성 > 테스트 통과하는 간단한 코드 구현 > 리팩토링을 통해 중복 제거

---

5장. 책임과 메시지

이상한 나라의 앨리스의 재판 과정을 기준으로 책임과 메시지에 대한 개념을 상세하게 설명

 

• 메시지
  • 메시지 전송 : 객체의 행동을 유발하는 행위
  • 메시지는 'HOW' 를 명시하지 않음, 단지 오퍼레이션을 통해 'WHAT'만 명시
  • 객체 지향의 핵심 메시지
    • 객체지향의 세계에서 객체들이 서로 협력하기 위해 사용할 수 있는 유일한 방법은 메시지를 전송하는 것
    • 독립된 객체의 상태와 행위에 대해 고민하지 말고 시스템의 기능을 구현하기 위해 객체가 다른 객체에게 제공해야 하는 메시지에 대해 고민해야 함
• 메서드
  • 객체가 수신할 수 있는 '메시지'와 메시지를 처리하기 위해 선택할 수 있는 '방법'이 메서드
  • 메시지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 사실은 다른 프로그래밍 언어와 객체지향 프로그래밍 언어를 구분 짓는 핵심적인 특징 중 하나
• 다형성
  • 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 의미
  • 기본적으로 다형성은 동일한 역할을 수행할 수 잇는 객체들 사이의 대체 가능성을 의미함
• What/Who 사이클
  • 객체 사이의 협력 관계를 설계하기 위해서는 먼저 '어떤 행위 what'를 수행할 것인지를 결정한 후에 '누가 who' 그 행위를 수행할 것인지를 결정해야 한다는 것(행위는 메시지를 의미함)
  • 수신 가능한 메시지가 모여 객체의 인터페이스를 구성
• 인터페이스와 구현의 분리 원칙 separation of interface and implementation
  • 객체를 설계할 때 객체 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 명확하게 분리해서 고려해야 한다는 것을 의미
  • 객체의 모든것이 외부에 공개되어 있다면 아무리 작은 부분을 수정하더라도 변경에 의한 파급효과가 객체 공동체에 영향을 미칠 수 있음

---

6장. 객체 지도

정기예금 도메인 모델을 예제로 하여 기능과 구조 등 상세하게 설명

• 구조 : 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현
  • 안정적인 재료
  • 도메인 : 사용자가 프로그램을 사용하는 대상 분야
  • 모델 : 대상을 추상화하고 단순화 해서 표현한 것
  • 도메인 모델 
    • 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
    • 객체지향은 사용자들이 이해하고 있는 도메인 구조와 최대한 유사하게 코드 구조화 가능
• 기능 : 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현
  • 불안정한 재료, 변경가능
  • 유스케이스
    • 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 함
    • 단순한 기능 나열이 아닌 이야기를 통해 연관된 기능들을 함께 묶음

---

7장. 함께 모으기

커피전문점 도메인을 예시로 개념, 명세, 구현 관점에 대해 설명

• 개념 관점 설계
  • 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현
  • 도메인이랑 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말하며 소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발됨
  • 실제 도메인 규칙과 최대한 유사하게 반영하는 것이 핵심
• 명세 관점 
  • 개발자의 영역인 소프트웨어로 초점이 옮겨짐
  • 명세 관점은 도메인의 개념이 아닌 실제로 소프트웨어 안에서 살아 숨쉬는 객체들의 책임에 초점을 맞추게 됨
  • 객체가 협력을 위해 '무엇'을 할 수 있는가에 초점을 맞춤
• 구현 관점
  • 프로그래머에게 가장 익숙한 관점
  • 구현 관점은 초점을 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것을 말함
  • 객체의 책임을 '어떻게' 수행할 것인가에 초점을 맞추며 인터페이스를 구현하는데 필요한 속성과 메서드를 클래스에 추가함
• 클래스는 세가지 관점을 모두 수용할 수 있도록 개념, 인터페이스, 구현의 관점이 드러나야 함