객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것이다. 세번째 걸음을 내디딜 수 있는지 여부는 협력에 참여하는 객체 들에게 얼마나 적절한 역할과 책임을 부여할 수 있느냐에 달려 있다. 객체지향의 마지막 걸음은 앞에서 설명한 개념들을 여러분이 사용하는 프로그래밍 언어라는 틀에 흐트러짐 없이 담아낼 수 있는 기술을 익히는 것이다.
《객체지향의 사실과 오해》가 첫번째 걸음과 두번째 걸음인 객체와 협력에 초점을 맞췄다면 《오브젝트: 코드로 이해하는 객체지향 설계》는 세번째와 네번째 걸음인 책임의 할당과 그 구현에 초점을 맞춘다. 이 책을 읽고 나면 객체에 적절한 역할과 책임을 부여하는 방법과 유연하면서도 요구사항에 적절한 협력을 설계하는 방법을 익히게 될 것이다. 나아가 프로그래밍 언어라는 도구를 이용해 객체지향의 개념과 원칙들을 오롯이 표현할 수 있는 방법 역시 익힐 수 있을 것이다.
★ 이 책에서 다루는 내용 ★
◎ 역할, 책임, 협력에 기반해 객체지향 프로그램을 설계하고 구현하는 방법
◎ 응집도와 결합도를 이용해 설계를 트레이드오프하는 방법
◎ 설계를 유연하게 만드는 다양한 의존성 관리 기법
◎ 타입 계층을 위한 상속과 코드 재사용을 위한 합성의 개념
◎ 다양한 설계 원칙과 디자인 패턴

▣ 들어가며: 프로그래밍 패러다임
01 패러다임의 시대
02 프로그래밍 패러다임
▣ 1장: 객체, 설계
01. 티켓 판매 애플리케이션 구현하기
02. 무엇이 문제인가
___예상을 빗나가는 코드
___변경에 취약한 코드
03. 설계 개선하기
___자율성을 높이자
___무엇이 개선됐는가
___어떻게 한 것인가
___캡슐화와 응집도
___절차지향과 객체지향
___책임의 이동
___더 개선할 수 있다
___그래, 거짓말이다!
04. 객체지향 설계
___설계가 왜 필요한가
___객체지향 설계
▣ 2장: 객체지향 프로그래밍
01. 영화 예매 시스템
___ 요구사항 살펴보기
02. 객체지향 프로그래밍을 향해
___ 협력, 객체, 클래스
___ 도메인의 구조를 따르는 프로그램 구조
___ 클래스 구현하기
___ 협력하는 객체들의 공동체
___ 협력에 관한 짧은 이야기
03. 할인 요금 구하기
___ 할인 요금 계산을 위한 협력 시작하기
___ 할인 정책과 할인 조건
___ 할인 정책 구성하기
04. 상속과 다형성
___ 컴파일 시간 의존성과 실행 시간 의존성
___ 차이에 의한 프로그래밍
___ 상속과 인터페이스
___ 다형성
___ 인터페이스와 다형성
05. 추상화와 유연성
___ 추상화의 힘
___ 유연한 설계
___ 추상 클래스와 인터페이스 트레이드오프
___ 코드 재사용
___ 상속
___ 합성
▣ 3장: 역할, 책임, 협력
01. 협력
___ 영화 예매 시스템 돌아보기
___ 협력
___ 협력이 설계를 위한 문맥을 결정한다
02. 책임
___ 책임이란 무엇인가
___ 책임 할당
___ 책임 주도 설계
___ 메시지가 객체를 결정한다
___ 행동이 상태를 결정한다
03. 역할
___ 역할과 협력
___ 유연하고 재사용 가능한 협력
___ 객체 대 역할
___ 역할과 추상화
___ 배우와 배역
▣ 4장: 설계 품질과 트레이드오프
01. 데이터 중심의 영화 예매 시스템
___ 데이터를 준비하자
___ 영화를 예매하자
02. 설계 트레이드오프
___ 캡슐화
___ 응집도와 결합도
03. 데이터 중심의 영화 예매 시스템의 문제점
___ 캡슐화 위반
___ 높은 결합도
___ 낮은 응집도
___ 캡슐화를 지켜라
04. 자율적인 객체를 향해
___ 스스로 자신의 데이터를 책임지는 객체
___ 캡슐화 위반
05. 하지만 여전히 부족하다
___ 높은 결합도
___ 낮은 응집도
___ 데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞춘다
06. 데이터 중심 설계의 문제점
___ 데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다
▣ 5장: 책임 할당하기
01. 책임 주도 설계를 향해
___ 데이터보다 행동을 먼저 결정하라
___ 협력이라는 문맥 안에서 책임을 결정하라
___ 책임 주도 설계
02. 책임 할당을 위한 GRASP 패턴
___ 도메인 개념에서 출발하기
___ 정보 전문가에게 책임을 할당하라
___ 높은 응집도와 낮은 결합도
___ 창조자에게 객체 생성 책임을 할당하라
03. 구현을 통한 검증
___ DiscountCondition 개선하기
___ 타입 분리하기
___ 다형성을 통해 분리하기
___변경으로부터 보호하기
___ Movie 클래스 개선하기
___ 변경과 유연성
04. 책임 주도 설계의 대안
___ 메서드 응집도
___ 객체를 자율적으로 만들자
▣ 6장: 메시지와 인터페이스
01. 협력과 메시지
___ 클라이언트-서버 모델
___ 메시지와 메시지 전송
___ 메시지와 메서드
___ 퍼블릭 인터페이스와 오퍼레이션
___ 시그니처
02. 인터페이스와 설계 품질
___ 묻지 말고 시켜라
___ 의도를 드러내는 인터페이스
___ 함께 모으기
03. 원칙의 함정
___ 디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다
___ 결합도와 응집도의 충돌
04. 명령-쿼리 분리 원칙
___ 반복 일정의 명령과 쿼리 분리하기
___ 명령-쿼리 분리와 참조 투명성
___ 책임에 초점을 맞춰라
▣ 7장: 객체 분해
01. 프로시저 추상화와 데이터 추상화
02. 프로시저 추상화와 기능 분해
___ 메인 함수로서의 시스템
___ 급여 관리 시스템
___ 급여 관리 시스템 구현
___ 하향식 기능 분해의 문제점
___ 언제 하향식 분해가 유용한가
03. 모듈
___ 정보 은닉과 모듈
___ 모듈의 장점과 한계
04. 데이터 추상화와 추상 데이터 타입
___ 추상 데이터 타입
05. 클래스
___ 클래스는 추상 데이터 타입인가
___ 추상 데이터 타입에서 클래스로 변경하기
___ 변경을 기준으로 선택하라
___ 협력이 중요하다
▣ 8장: 의존성 관리하기
01. 의존성 이해하기
___ 변경과 의존성
___ 의존성 전이
___ 런타임 의존성과 컴파일타임 의존성
___ 컨텍스트 독립성
___ 의존성 해결하기
02. 유연한 설계
___ 의존성과 결합도
___ 知識이 결합을 낳는다
___ 추상화에 의존하라
___ 명시적인 의존성
___ new는 해롭다
___ 가끔은 생성해도 무방하다
___ 표준 클래스에 대한 의존은 해롭지 않다
___ 컨텍스트 확장하기
___ 조합 가능한 행동
▣ 9장: 유연한 설계
01. 개방-폐쇄 원칙
___ 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라
___ 추상화가 핵심이다
02. 생성 사용 분리
___ FACTORY 추가하기
___ 순수한 가공물에게 책임 할당하기
03. 의존성 주입
___ 숨겨진 의존성은 나쁘다
04. 의존성 역전 원칙
___ 추상화와 의존성 역전
___ 의존성 역전 원칙과 패키지
05. 유연성에 대한 조언
___ 유연한 설계는 유연성이 필요할 때만 옳다
___ 협력과 책임이 중요하다
▣ 10장: 상속과 코드 재사용
01. 상속과 중복 코드
___ DRY 원칙
___ 중복과 변경
___ 상속을 이용해서 중복 코드 제거하기
___ 강하게 결합된 Phone과 NightlyDiscountPhone
02. 취약한 기반 클래스 문제
___ 불필요한 인터페이스 상속 문제
___ 메서드 오버라이딩의 오작용 문제
___ 부모 클래스와 자식 클래스의 동시 수정 문제
03. Phone 다시 살펴보기
___ 추상화에 의존하자
___ 차이를 메서드로 추출하라
___ 중복 코드를 부모 클래스로 올려라
___ 추상화가 핵심이다
___ 의도를 드러내는 이름 선택하기
___ 세금 추가하기
04. 차이에 의한 프로그래밍
▣ 11장: 합성과 유연한 설계
01. 상속을 합성으로 변경하기
___ 불필요한 인터페이스 상속 문제: java.util.Properties와 java.util.Stack
___ 메서드 오버라이딩의 오작용 문제: InstrumentedHashSet
___ 부모 클래스와 자식 클래스의 동시 수정 문제: PersonalPlaylist
02. 상속으로 인한 조합의 폭발적인 증가
___ 기본 정책과 부가 정책 조합하기
___ 상속을 이용해서 기본 정책 구현하기
___ 기본 정책에 세금 정책 조합하기
___ 기본 정책에 기본 요금 할인 정책 조합하기
___ 중복 코드의 덫에 걸리다
03. 합성 관계로 변경하기
___ 기본 정책 합성하기
___ 부가 정책 적용하기
___ 기본 정책과 부가 정책 합성하기
___ 새로운 정책 추가하기
___ 객체 합성이 클래스 상속보다 더 좋은 방법이다
04. 믹스인
___ 기본 정책 구현하기
___ 트레이트로 부가 정책 구현하기
___ 부가 정책 트레이트 믹스인하기
___ 쌓을 수 있는 변경
▣ 12장: 다형성
01. 다형성
02. 상속의 양면성
___ 상속을 사용한 강의 평가
___ 데이터 관점의 상속
___ 행동 관점의 상속
03. 업캐스팅과 동적 바인딩
___ 같은 메시지, 다른 메서드
___ 업캐스팅
___ 동적 바인딩
04. 동적 메서드 탐색과 다형성
___ 자동적인 메시지 위임
___ 동적인 문맥
___ 이해할 수 없는 메시지
___ self 대 super
05. 상속 대 위임
___ 위임과 self 참조
___ 프로토타입 기반의 객체지향 언어
▣ 13장: 서브클래싱과 서브타이핑
01. 타입
___ 개념 관점의 타입
___ 프로그래밍 언어 관점의 타입
___ 객체지향 패러다임 관점의 타입
02. 타입 계층
___ 타입 사이의 포함관계
___ 객체지향 프로그래밍과 타입 계층
03. 서브클래싱과 서브타이핑
___ 언제 상속을 사용해야 하는가
___ is-a 관계
___ 행동 호환성
___ 클라이언트의 기대에 따라 계층 분리하기
___ 서브클래싱과 서브타이핑
04. 리스코프 치환 원칙
___ 클라이언트와 대체 가능성
___ is-a 관계 다시 살펴보기
___ 리스코프 치환 원칙은 유연한 설계의 기반이다
___ 타입 계층과 리스코프 치환 원칙
05. 계약에 의한 설계와 서브타이핑
___ 서브타입과 계약
▣ 14장: 일관성 있는 협력
01. 핸드폰 과금 시스템 변경하기
___ 기본 정책 확장
___ 고정요금 방식 구현하기
___ 시간대별 방식 구현하기
___ 요일별 방식 구현하기
___ 구간별 방식 구현하기
02. 설계에 일관성 부여하기
___ 조건 로직 대 객체 탐색
___ 캡슐화 다시 살펴보기
03. 일관성 있는 기본 정책 구현하기
___ 변경 분리하기
___ 변경 캡슐화하기
___ 협력 패턴 설계하기
___ 추상화 수준에서 협력 패턴 구현하기
___ 구체적인 협력 구현하기
___ 협력 패턴에 맞추기
___ 패턴을 찾아라
▣ 15장: 디자인 패턴과 프레임워크
01. 디자인 패턴과 설계 재사용
___ 소프트웨어 패턴
___ 패턴 분류
___ 패턴과 책임-주도 설계
___ 캡슐화와 디자인 패턴
___ 패턴은 출발점이다
02. 프레임워크와 코드 재사용
___ 코드 재사용 대 설계 재사용
___ 상위 정책과 하위 정책으로 패키지 분리하기
___ 제어 역전 원리
▣ 마치며: 나아가기
▣ 부록A: 계약에 의한 설계
01. 협력과 계약
___ 부수효과를 명시적으로
___ 계약
02. 계약에 의한 설계
___사전조건
___ 사후조건
___ 불변식
03. 계약에 의한 설계와 서브타이핑
___ 계약 규칙
___ 가변성 규칙
___ 함수 타입과 서브타이핑
▣ 부록B: 타입 계층의 구현
___ 클래스를 이용한 타입 계층 구현
___ 인터페이스를 이용한 타입 계층 구현
___ 추상 클래스를 이용한 타입 계층 구현
___ 추상 클래스와 인터페이스 결합하기
___ 덕 타이핑 사용하기
___ 믹스인과 타입 계층
▣ 부록C: 동적인 협력, 정적인 코드
01. 동적 모델과 정적 모델
___ 행동이 코드를 결정한다
___ 변경을 고려하라
02. 도메인 모델과 구현
___ 도메인 모델에 관하여
___ 몬스터 설계하기
___ 행동과 변경을 고려한 도메인 모델
___ 분석 모델, 설계 모델, 그리고 구현 모델
▣ 부록D: 참고문헌
___ 참고문헌

조영호 (지은이)