객체지향의 사실과 오해 리뷰 #객체지향 책 추천

책 소개

객체지향을 공부한다면, 누구나 한 번 쯤 읽어보면 좋을 책.

 

객체지향의 개념을 처음 접하는 사람도 쉽게 이해할 수 있는 설명과 예시로 이루어져 있고,

객체지향의 개념을 실무에서 적용해본 사람도, 새로운 인사이트를 얻어갈 수 있는 책이라고 생각합니다.

 

개인적으로는 반복되는 설명이 많아 읽는 데에 피로감이 다소 있었습니다만,

어느 모로 보나 쉽고, 재밌고, 유익한 책인 것만은 확실합니다.

 

 

저는 객체지향 개념에서 사용되는 단어들,

예컨대 책임, 상태, 추상화, 캡슐화 등..

단어만으로는 뜻이 와닿았던 적이 없었습니다.

 

하지만 모방이 아닌 은유(저는 차용이라고도 이해했습니다)를 통해

실세계의 개념을 객체지향에 적용하고,

객체지향만의 고유의 특징을 이해하며, (음료수가 스스로 마셔질 수 있다..!)

그 안에서 어려운 단어들을 풀어서 설명해주신 방식이 너무 좋았습니다.

 

아직 갈 길이 멀었지만,

그래도 내가 객체지향을 하고 있구나 라는 생각은 들게 된 것 같습니다.

 

 

아래에서는 책의 내용을 되짚어보고자 합니다.

 

 

 

 

---

책 내용 상세 정리

(* 편의상 반말을 사용함을 양해 부탁드립니다.)

 

 

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

객체지향은 역할, 책임, 협력으로 이루어진다.

 

[카페 예시]

• 역할 : 손님, 캐셔, 바리스타
• 책임 : 주문, 커피 오더, 커피 만들기
• 협력 : 커피 주문 전 과정

객체지향이란 시스템을 ‘상호작용하는 자율적인 객체들의 공동체’로 바라보는 것

자율적인 객체란, 상태와 행동을 함께 지니며, 스스로를 책임지는 객체

 

각 역할은 협력하고, 역할은 관련된 책임의 집합.

 

객체 사이 상호작용은 ‘메시지’로만 이루어지고,

메시지를 수신한 객체는 적합한 메서드를 자율적으로 선택

 

 

 

 

2장 - 이상한 나라의 객체

객체는 상태, 행동, 식별자로 이루어져 있다.

 

'이상한 나라의 앨리스 예시'로 그것을 설명한다.

예시 내용을 요약하면 다음과 같다.

 

높이가 40cm인 문으로 나가 아름다운 정원에서 뛰어 놀고 싶은 앨리스.

앨리스에게 주어진 것은 '마시면 키가 줄어드는 음료수', '먹으면 몸이 커지는 케이크'이다.

 

 

상태

• 엘리스의 키
• 음료수의 양

행동

• 음료수를 마시다
• 케이크를 먹자
• (음료수 입장에서) 마셔지다 → 실세계와 객체지향 세계가 다른 점!

식별자

• 고유의 객체를 구별할 수 있는 값
• 엘리스의 국적 + 주민번호 쯤이 되겠다..

 

캡슐화란?

• 객체의 상태를 (캡슐 안에 숨겨두어) 외부로 노출하지 않는다.
• 예를 들면, 앨리스 객체의 키에 alice.height 로는 접근할 수 없고, 앨리스 객체에 getHeight() 메서드가 있다면 그것으로 값을 구해올 수 는 있는 것.
• 객체는 외부에 상태가 아닌 행동만을 노출하고, 외부에서는 행동만을 통해서 객체에 접근한다.

 

행동이 상태를 결정한다.

 

앨리스 예시에서, 키와 위치를 먼저 생각하는 것이 아니라,

행동을 먼저 생각하고 필요한 상태를 정의한다.

 

객체지향은 현실세계의 모방이 아닌 은유다!

객체지향 세계는 현실세계의 비유를 통해 쉽게 이해할 수 있다. (변수명을 지을 때도, 현실세계의 은유를 빌리면 훨씬 직관적이다!)

하지만 현실과 다른 무궁무진한 상상을 구현할 수 있으니 현실세계 사고에 갇히지 말자. (음료수가 스스로 마셔지는 것 또한 그렇다.)

--> 객체스럽게 설계하라!

 

 

 

 

3장 - 타입과 추상화

3장에서는 트럼프 카드의 몸체를 지닌 하트 여왕, 스페이드 정원사, 클로버 병사의 행렬을 발견하는 앨리스를 묘사한다.

 

 

추상화

명확한 이해를 위해, 특정 절차나 물체를 생략하거나 감춰 복잡도는 줄이는 방법.

• 첫 번째 차원 : 공통점은 취하고 차이점은 버리는 일반화
• 두 번째 차원 : 불필요한 세부 사항을 제거

개념

특정 객체가 어떤 그룹에 속하는지 결정하는 것

• 비행기, 자동차, 사람 등..
• 앨리스 예시 : 트럼프!

 

타입

컴퓨터공학에서의 개념이자, 타입의 관점에서 본 객체

1. 객체가 타입에 속하는지 결정하는 것은 객체의 행동
2. 객체들이 동일한 행동을 수행할 수 있다면, 동일한 타입
3. 객체의 내부적 표현(행동의 구현 방식, 상태)은 외부로부터 감춰진다

 

타입의 계층

트럼프 - 트럼프 인간

트럼프는

• 납작 엎드리기
• 뒤집어지기

트럼프 인간은

• 납작 엎드리기
• 뒤집어지기
• 걸을 때마다 몸이 종이처럼 좌우로 펄럭이기

트럼프는 트럼프 인간의 일반화(슈퍼타입)

트럼프 인간은 트럼프의 특수화(서브타입)

 

정적 모델과 동적 모델

객체는 동적이다 -> 시간에 따라 상태는 변한다

타입은 정적이다 -> 정적인 관점에서 객체를 묘사한다

결국 타입은 추상화다!

 

 

 

 

4장 - 역할,  책임,  협력

 

재판이라는 협력

1. 왕이 판사로서 증인을 불러오라고 요청,
2. 토끼는 증인인 모자 장수를 부름,
3. 모자 장수는 법정에 입장,
4. 왕은 모자 장수에게 증언을 요청,
5. 모자 장수는 증언

객체지향 설계는

1. 협력이라는 문맥 속에서 책임을 고민
2. 책임을 적절한 객체에 부여

하는 순서로 작성되어야 한다.

 

역할

역할은 책임의 집합이다.

 

역할은 협력을 추상화하고, 유연한 객체지향 설계를 만든다.

 

판사 역할 : 왕, 왕비 수행 가능

증인 : 모자 장수, 공작 부인의 요리사, 앨리스 수행 가능

 

이처럼 ‘판사’, ‘증인’의 역햘로 구성된 ‘재판’이라는 협력은 추상화되어 있고, 유연한 설계이다.

 

객체지향 설계 기법

• 책임 주도 설계
  • 책임들을 식별하고, 적합한 객체에게 할당하는 방식으로 설계
• 디자인 패턴
  • 책임 주도 설계의 결과를 표현하는 것으로, 반복되는 문제 해결을 위한 방법과 절차를 만들어 놓은 틀
  ex: MVC, MVP, MVVM
• 테스트 주도 개발 : 응집도가 높고 결합도가 낮은 클래스로 구성된 시스템을 개발할 수 있는 좋은 방식.

 

 

 

 

5장 - 책임과 메시지

 

책임

책임은 적당히 추상적이면서 구체적이어야 한다.

→ ‘증언하라’는 책임

책임은 how가 아닌 what을 설명

 

메시지

메시지 → 메서드 : 모자장수.증언하라(어제, 왕국)

 

모자장수 : 수신자

증언하라 : 메시지 이름

어제, 왕국 : 인자

 

같은 메시지를 보내도, 수신자가 다르게 결정할 수 있다. → 다형성!

 

What/Who 사이클 : 책임 주도 설계의 핵심 → 어떤 행위가 필요한지 결정하고, 누가 수행할 것인지를 결정한다.

 

묻지 말고 시켜라! (Don’t ask, 디미터 법칙) → 객체가 자율적으로 구현 → 캡슐화 보장, 결합도 낮게 유지

 

인터페이스와 구현

인터페이스 : 객체 외부

구현 : 객체 내부

인터페이스는 구현과 분리되어야 한다.

 

인터페이스의 3가지 원칙

• 좀 더 추상적인 인터페이스 : 객체의 자율성 보장
• 최소 인터페이스 : 객체 내부 동작에 대해 가능한 적은 정보만 노출
• 인터페이스와 구현 간 차이를 인식

캡슐화 : 자율성 보존을 위해 구현을 외부로부터 감추는 것

데이터 캡슐화 : 상태와 행동을 하나의 단위로 묶음

 

자율적인 책임은!

• 협력을 단순하게 만든다 (추상화)
• 외부와 내부가 명확하게 분리 (캡슐화)
• 내부를 변경해도 외부에 영향 X (변경의 파급효과가 객체 내부로 캡슐화 → 객체 간 결합도가 낮아짐)
• 협력의 대상을 다양하게 선택할 수 있는 유연성 제공 (+ 재사용성 증가)
• 객체 역할 이해가 쉬워짐 (응집도 증가)

 

 

 

6장 - 객체 지도

• 소프트웨어 제품 설계 → 기능 설계 + 구조 설계

도메인 모델

• 구조를 설계하기 위한 모델
• 도메인 : 프로그램 사용 분야 (은행, 게임, 병원 등)
• 모델 : 대상을 단순화한 구조
• 도메인 모델 : 대상 영역의 지식을 단순하게 구조화한 것

계좌

• 계좌번호
• 예금액

이자

• 금액
• 지급일자

위의 도메인 모델은 코드에서 사용할 개념과 관계를 제공 -> 그것을 구현하여 코드 작성

 

Account 객체 설계

상태

• accountNumber
• amount

메서드

• calculateInterest(when)

 

유스케이스

사용자와 시스템 간 상호작용을 텍스트로 정리한 것

 

예시)

유스케이스명 : 중도 해지 이자액을 계산한다

일차 액터 : 예금주

주요 성공 시나리오:

1. 예금주가 정기예금 계좌를 선택한다.
2. 시스템은 정기예금 계좌 정보를 보여준다.
3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.
4. 시스템은 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 제공한다.

확장 : 3a. 사용자는 해지 일자를 다른 일자로 입력할 수 있다.

 

유스케이스의 특징

1. 텍스트다.
2. 하나가 아닌 여러 시나리오들의 집합이다.
3. 단순한 피처가 아닌, 연관된 기능의 묶음이다.
4. 사용자 인터페이스와 관련된 세부 정보를 포함하면 안 된다.
5. 내부 설계 정보를 포함하면 안 된다.

 

책임 주도 설계는

유스케이스 작성 + 도메인 모델 → 협력 관계 및 메시지 정의 → 코드 구현

의 순서로 진행되어야 한다.

 

 

 

 

7장 - 함께 모으기

 

개념 관점 : 도메인의 개념과 관계를 보는 관점

명세 관점 : 인터페이스 관점

구현 관점 : 코드 관점

코드에 각 관점이 잘 드러나게 설계해라

 

도메인 개념 참조 → 변화에 쉽게 대응 가능(안정적이고 이해가 쉽다)

인터페이스와 구현을 분리하라! → 변화에 유연하게 하라!

 

 

 

 

---

 

 

 

감사합니다!