C++ API 디자인

chpater 1 소개
1.1 애플리케이션 프로그래밍 인터페이스
1.1.1 계약과 계약자
1.1.2 C++로 구현하는 API
1.2 API 설계의 차별화되는 특징
1.3 API를 사용하는 이유
1.3.1 좀 더 견고한 코드
1.3.2 코드 재사용
1.3.3 병렬 개발
1.4 API를 사용하지 말아야 할 때
1.5 예제 API
1.5.1 API 계층
1.5.2 실세계 예제
1.6 파일 포맷과 네트워크 프로토콜
1.7 이 책의 구성

chpater 2 품질
2.1 문제 도메인 모델
2.1.1 훌륭한 추상화 제공
2.1.2 핵심 객체 모델링
2.2 구체적인 구현 숨기기
2.2.1 물리적 은닉: 선언 vs 정의
2.2.2 논리적 은닉: 캡슐화
2.2.3 멤버 변수 감추기
2.2.4 메서드 구현 숨기기
2.2.5 클래스 구현 숨기기
2.3 작게 완성하기
2.3.1 지나친 약속은 금지
2.3.2 가상 함수의 추가는 신중하게
2.3.3 편리한 API
2.4 쉬운 사용성
2.4.1 한눈에 들어오는
2.4.2 잘못 사용하기에도 어렵게
2.4.3 일관성 있는
2.4.4 수직적인
2.4.5 견고한 자원 할당
2.4.6 플랫폼 독립성
2.5 느슨한 연결
2.5.1 이름만을 사용한 연결
2.5.2 클래스 연결 줄이기
2.5.3 의도적인 중복
2.5.4 매니저 클래스
2.5.5 콜백과 옵저버, 알림
2.6 안정화와 문서화, 테스트

chpater 3 패턴
3.1 Pimpl 관용법
3.1.1 Pimpl 사용
3.1.2 의미론적 복사
3.1.3 Pimpl과 스마트 포인터
3.1.4 Pimpl의 장점
3.1.5 Pimpl의 단점
3.1.6 C의 Opaque 포인터
3.2 싱글톤
3.2.1 C++의 싱글톤 구현
3.2.2 스레드에 안전한 싱글톤 만들기
3.2.3 싱글톤 vs 의존성 삽입
3.2.4 싱글톤 vs 모노스테이트
3.2.5 싱글톤 vs 세션 상태
3.3 팩토리 메서드
3.3.1 추상 기본 클래스
3.3.2 단순한 팩토리 예제
3.3.3 확장 가능한 팩토리 예제
3. 4 API 래핑 패턴
3.4.1 프록시 패턴
3.4.2 어댑터 패턴
3.4.3 퍼사드 패턴
3.5 옵저버 패턴
3.5.1 모델-뷰-컨트롤러
3.5.2 옵저버 패턴 구현
3.5.3 푸시 옵저버 VS 풀 옵저버

chpater 4 설계
4.1 좋은 설계를 위한 사례
4.1.1 기술적 부채의 증가
4.1.2 부채 상환
4.1.3 멀리 보는 설계
4.2 기능적 요구사항 수집
4.2.1 기능적 요구사항
4.2.2 기능적 요구사항의 예
4.2.3 요구사항 유지보수
4.3 유즈 케이스 생성
4.3.1 유즈 케이스 개발
4.3.2 유즈 케이스 템플릿 사용
4.3.3 좋은 유즈 케이스 작성
4.3.4 요구사항과 애자일 개발
4.4 API 설계 요소
4.5 아키텍처 설계
4.5.1 아키텍처 수립
4.5.2 아키텍처의 제약사항
4.5.3 주요 추상화 객체 식별
4.5.4 핵심 객체 생성
4.5.5 아키텍처 관점 패턴
4.5.6 아키텍처 논의
4.6 클래스 설계
4.6.1 객체 지향 개념
4.6.2 클래스 설계의 선택사항
4.6.3 상속 사용
4.6.4 리스코브 대리 원칙
4.6.5 개방/폐쇄 원칙
4.6.6 데메테르의 법
4.6.7 클래스 이름
4.7 함수 설계
4.7.1 함수 설계의 선택사항
4.7.2 함수 이름
4.7.3 함수 파라미터
4.7.4 예외 처리

chpater 5 API 개발 방법
5.1 일반 C API
5.1.1 ANSI C 기능
5.1.2 ANSI C API의 장점
5.1.3 ANSI C로 API 작성
5.1.4 C++ 코드에서 C 함수 호출
5.1.5 사례 연구: FMOD C API
5.2 객체 지향 C++ API
5.2.1 객체 지향 API의 장점
5.2.2 객체 지향 API의 단점
5.2.3 사례 연구: FMOD C++ API
5.3 템플릿 기반 API
5.3.1 템플릿 기반 API 예제 245
5.3.2 템플릿 vs 매크로
5.3.3 템플릿 기반 API의 장점
5.3.4 템플릿 기반 API의 단점
5.4 데이터 주도 API
5.4.1 데이터 주도 웹 서비스
5.4.2 데이터 주도 API의 장점
5.4.3 데이터 주도 API의 단점
5.4.4 가변형 파라미터 리스트 지원
5.4.5 사례 연구: FMOD 데이터 주도 API

chpater 6 C++의 올바른 사용법
6.1 네임스페이스
6.2 생성자와 할당
6.2.1 컴파일러 생성 함수 제어
6.2.2 생성자와 할당 정의
6.2.3 Explicit 키워드
6.3 상수 정확성
6.3.1 메서드 상수 정확성
6.3.2 파라미터 상수 정확성
6.3.3 리턴 값 상수 정확성
6.4 템플릿
6.4.1 템플릿 용어
6.4.2 암시적 인스턴스화 API 설계
6.4.3 명시적 인스턴스화 API 설계
6.5 연산자 오버로딩
6.5.1 오버로드 가능한 연산자
6.5.2 자유 연산자와 멤버 연산자
6.5.3 클래스에 새 연산자 추가
6.5.4 연산자 문법
6.5.5 형 변환 연산자
6.6 함수 파라미터
6.6.1 포인터 피라미터 vs 참조 파라미터
6.6.2 기본 파라미터
6.7 상수에 #DEFINE 사용 금지
6.8 프렌드 사용 금지
6.9 심벌 노출
6.10 코딩 규칙

chpater 7 성능
7.1 상수 참조로 입력 파라미터 전달
7.2 #INCLUDE 의존성 최소화
7.2.1 “한곳에 몰아두는” 헤더 금지
7.2.2 전방 선언
7.2.3 #include 중복 방지
7.3 상수 선언
7.3.1 새로운 constexpr 키워드 3
7.4 초기화 리스트
7.5 메모리 최적화
7.6 필요시까지 인라인 사용 금지
7.7 카피-온-라이트
7.8 요소 반복
7.8.1 반복자
7.8.2 임의 접근
7.8.3 배열 참조
7.9 성능 분석
7.9.1 시간 기반 분석
7.9.2 메모리 기반 분석
7.9.3 멀티스레드 분석

chpater 8 버전 관리
8.1 버전 번호
8.1.1 버전 번호의 의미
8.1.2 일부만 아는 버전 규칙
8.1.3 버전 API 생성
8.2 소프트웨어 브랜치 전략
8.2.1 브랜치 전략
8.2.2 브랜치 정책
8.2.3 API와 병렬 브랜치
8.2.4 파일 포맷과 병렬 제품
8.3 API의 수명 주기
8.4 호환성 수준
8.4.1 하위 호환성
8.4.2 기능적 호환성
8.4.3 소스 호환성
8.4.4 이진 호환성
8.4.5 상위 호환성
8.5 하위 호환성 유지
8.5.1 기능 추가
8.5.2 기능 변경
8.5.3 기능 교체
8.5.4 기능 제거
8.6 API 리뷰
8.6.1 API 리뷰의 목적
8.6.2 사전 릴리즈 리뷰
8.6.3 사전 커밋 API 리뷰

chpater 9 문서화
9.1 문서화의 이유
9.1.1 행동 정의
9.1.2 인터페이스 계약 문서화
9.1.3 행동 변화에 대한 의사소통
9.1.4 문서화의 대상
9.2 문서화의 유형
9.2.1 자동화된 API 문서화
9.2.2 개요 문서화
9.2.3 예제와 튜토리얼
9.2.4 릴리즈 노트
9.2.5 라이선스 정보
9.3 문서 활용
9.4 DOXYGEN 사용
9.4.1 구성 파일
9.4.2 주석 스타일과 명령
9.4.3 API 주석
9.4.4 파일 주석
9.4.5 클래스 주석
9.4.6 메서드 주석
9.4.7 열거형 주석
9.4.8 예제 헤더 문서화

chpater 10 테스트
10.1 테스트 코드가 필요한 이유
10.2 API 테스트의 유형
10.2.1 단위 테스트
10.2.2 통합 테스트
10.2.3 성능 테스트
10.3 좋은 테스트 코드 작성
10.3.1 좋은 테스트 코드의 특성
10.3.2 테스트의 대상
10.3.3 테스트의 선택과 집중
10.3.4 QA 팀의 협업
10.4 테스트 가능한 코드의 작성
10.4.1 테스트 주도 개발
10.4.2 스텁(Stub)과 목(Mock) 객체
10.4.3 Private 코드 테스트
10.4.4 테스트 결과 표명
10.4.5 계약 프로그래밍
10.4.6 기록과 재생 기능
10.4.7 국제화 지원
10.5 테스트 자동화 도구
10.5.1 테스트 하네스
10.5.2 코드 커버리지
10.5.3 버그 추적
10.5.4 지속적인 빌드 시스템

chpater 11 스크립팅
11.1 스크립트 바인딩 추가
11.1.1 확장 vs 임베딩
11.1.2 스크립팅의 장점
11.1.3 언어 호환성 문제
11.1.4 언어 장벽 교차
11.2 스크립트 바인딩 기법
11.2.1 Boost Python
11.2.2 SWIG
11.2.3 Python-SIP
11.2.4 COM 자동화
11.2.5 CORBA
11.3 BOOST PYTHON을 사용한 PYTHON 바인딩 추가
11.3.1 Boost Python 바인딩
11.3.2 Boost Python을 사용한 C++ API 래핑
11.3.3 생성자
11.3.4 Python API 확장
11.3.5 C++의 상속
11.3.6 교차 언어 다형성
11.3.7 반복자 지원
11.3.8 종합
11.4 SWIG를 이용한 RUBY 바인딩 추가
11.4.1 SWIG를 사용한 C++ API 래핑
11.4.2 Ruby API 개선
11.4.3 생성자
11.4.4 Ruby API 확장
11.4.5 C++의 상속
11.4.6 교차 언어 다형성
11.4.7 종합

chpater 12 확장성
12.1 플러그인을 통한 확장
12.1.1 플러그인 모델의 개요
12.1.2 플러그인 시스템 설계 이슈
12.1.3 C++로 플러그인 개발
12.1.4 플러그인 API
12.1.5 예제 플러그인
12.1.6 플러그인 매니저
12.1.7 플러그인 버전 관리
12.2 상속을 통한 확장
12.2.1 기능 추가
12.2.2 기능 수정
12.2.3 상속과 STL
12.2.4 상속과 열거형
12.2.5 비지터 패턴
12.2.6 서브 클래스 사용 금지
12.3 템플릿을 통한 확장
12.3.1 정책 기반 템플릿
12.3.2 정교하게 반복되는 템플릿 패턴

만약 당신이 C++로 코드를 개발하고 있고 또 누군가가 그 코드를 사용한다면, 당신은 API 설계자이고 이 책은 그런 분을 위해 쓰여졌다. 당신이 작성하는 코드 중 인터페이스는 가장 중요하다. 왜냐하면 인터페이스에서 발생하는 문제는 구현 코드에서 버그를 수정하는 것보다 더 많은 비용을 초래하기 때문이다.

예를 들어, 인터페이스의 변경은 코드를 기반으로 하는 또 다른 모든 애플리케이션에 영향을 비칠 수 있는 반면 구현 코드의 변경은 새로운 버전의 API를 사용할 때 큰 노력을 들이지 않고 투명하게 클라이언트 애플리케이션으로 쉽게 통합될 수 있기 때문이다. 경제에서 사용되는 용어로 표현하자면, 낮은 품질의 인터페이스는 여러분의 코드를 오래 지속시키지 못한다. 그렇기 때문에 어떻게 하면 고수준의 인터페이스를 생성할 수 있는지를 학습하는 것이 가장 기본이 되는 엔지니어링의 기술이고 이 책에서 이야기 하고자 하는 바이다.

<저자 서문 중>