성공과 실패를 결정하는 1%의 객체 지향 원리

Chapter 01 객체 지향은 소프트웨어 개발을 편하게 하는 기술
01_객체 지향은 소프트웨어 개발의 종합 기술
02_객체 지향은 마법이 아니다
03_정말로 어려운 것은 소프트웨어 개발이다
04_ 프로그래밍 언어로부터 종합 기술로 진화
05혼란스러운 상태에서 이해하려고 하기 때문에 어렵다
06_혼란 Ⅰ - 용어의 홍수
07_혼란 Ⅱ - 비유의 남용
08_혼란 Ⅲ - 무엇이든지 객체 증후군
09_3가지 혼란이 어려움을 증폭시킨다
10_잘 모르기 때문에 신비롭게 느껴진다
11_3가지 혼란을 벗어나면 실체가 보이기 시작한다
12_이 책의 구성

Chapter 02 객체 지향과 현실 세계는 크게 다르다
01_개념으로만 이해하려 하면 더 혼란스럽다
02_객체 지향을 현실 세계에 대비하여 설명한다
03_클래스는 종류, 인스턴스는 구체적인 것
04_폴리모피즘은 메시지 보내는 방법이 공통이다
05_상속은 공통점과 상이점을 체계적으로 분류해서 정리한다
06_객체 지향과 현실 세계는 크게 다르다
07_클래스와 인스턴스, 상속에 관한 착각
08_폴리모피즘에 대한 착각
09_현실 세계를 그대로 소프트웨어로 표현하지는 않는다
10_현실 세계와의 대비는 비유와 구분하는 것이 비결

Chapter 03 OOP를 이해하는 지름길은 프로그래밍 언어의 역사에 있다
01_OOP는 필연성을 가지고 등장했다
02_초창기에는 기계 언어로 프로그램을 작성했다
03_프로그램 언어의 첫걸음은 어셈블리 언어
04_고급 언어의 발명으로 보다 인간에게 친숙해진 프로그램
05_알기 쉬움을 중시하는 구조적 프로그래밍
06_서브루틴의 높은 독립성은 유지 보수의 강점
07_「GOTO 없는 프로그램」을 실현하는 구조적 언어
08_진화 방향은 유지 보수성과 재사용성 중시로 변화했다
09_남겨진 문제는 전역변수와 빈약한 재사용
[컬럼] COBOL 컴파일러의 닭과 계란 이야기

Chapter 04 OOP는 불필요한 부분을 생략하고 정리 정돈하는 프로그래밍 기술
01_OOP에는 있지만 구조적 언어에는 없는 3가지 구조
02_3대 요소 Ⅰ - 클래스에 구비된 3가지 구조
03_클래스의 효능 Ⅰ - 정리
04_클래스의 효능 Ⅱ - 감추기
05_클래스의 효능 Ⅲ - 많이 만들기
06_인스턴스 변수는 「클래스 내에서만의 전역변수」
07_3대 요소 Ⅱ - 호출하는 쪽을 공통화하는 폴리모피즘
08_3대 요소 Ⅲ - 클래스 정의의 중복을 배제하는 상속
09_3대 요소의 종합
10_형(型)에 맞추면 프로그래머는 편하다
11_프로그래밍 언어는 「퇴화」했다?
12_더욱 진화한 OOP의 구조
13_진화한 OOP 구조 Ⅰ - 패키지
14_진화한 OOP 구조 Ⅱ - 예외
15_진화한 OOP 구조 Ⅲ - 자투리 수집
16_OOP 진화의 종합
17_OOP를 살리고 죽이는 것은 프로그래머의 마음가짐 나름이다

Chapter 05 메모리 구조의 이해는 프로그래머의 소양
01_OOP 프로그램의 동작 구조를 이해하자
02_컴파일러와 인터프리터의 2가지 실행 방식
03_CPU는 복수의 스레드를 가지고 실행한다
04_정적 영역, 힙 영역, 스택 영역으로 관리한다
05_OOP의 특징은 메모리 사용법에 있다
06_클래스 정보는 클래스마다 1개만 로드된다
07_인스턴스를 만들 때 힙 영역이 사용된다
08_변수에는 인스턴스의 「포인터」가 저장된다
09_인스턴스를 저장하는 변수의 복사에 요주의
10_폴리모피즘은 다른 클래스가 같은 얼굴로 보여진다
11_상속된 정보의 종류에 따라 메모리 배치는 달라진다
12_고립된 인스턴스는 자투리 수집기가 처리한다
[컬럼] OOP는 메모리 덤프 내용을 보기 어렵다

Chapter 06 OOP가 가져다 준 소프트웨어와 아이디어의 재사용
01_OOP의 우수한 구조에 의해 재사용이 진행된다
02_클래스 라이브러리는 OOP의 소프트웨어 구성 요소의 집합
03_표준의 클래스 라이브러리는 언어 사양의 일부
04_프레임워크에는 전혀 다른 2가지 의미가 있다
05_프레임워크는 어플리케이션의 미완성품
06_클래스 라이브러리는 국제적으로 재사용된다
07_OOP의 구조를 실행 환경에 확장시킨 컴포넌트
08_설계 패턴은 우수한 설계 아이디어의 집합
09_설계 패턴은 클래스 라이브러리 탐험의 이정표
10_설계 패턴은 객체 지향 설계의 본보기
11_설계 이외의 분야에도 퍼지고 있는 아이디어의 재사용
12_클래스 라이브러리와 패턴으로 알 수 있는 재사용의 혜택

Chapter 07 범용 정리술로 둔갑한 객체 지향
01_소프트웨어는 현실 세계를 그대로 표현하지 않는다
02_집합론과 역할 분담에 적용된다
03_상위 공정에서 「범용 정리술」로 둔갑했다
04_2가지 의미를 갖는 것이 혼란을 가져온다
05_OOP의 확장과 정리술로 분류해서 생각할 수 있다
06_왜 범용 정리술로 둔갑한 것일까?

Chapter 08 UML은 형태가 없는 소프트웨어를 보는 도구
01_UML은 소프트웨어의 기능과 구조를 나타내는 그림 그리는 법
02_UML에는 13종류의 다이어그램이 있다
03_UML의 사용 방법은 크게 3가지
04_UML의 사용법 Ⅰ - 프로그램 구조와 동작을 표현한다
05_클래스 다이어그램으로 OOP의 프로그램 구조를 표현한다
06_시퀀스 다이어그램과 커뮤니케이션 다이어그램으로 동적인 정보를 표현한다
07_UML의 사용법 Ⅱ - 범용 정리술의 산출물을 표현한다
08_집합론으로 정리한 결과를 클래스 다이어그램으로 표현한다
09_역할 분담은 시퀀스 다이어그램과 커뮤니케이션 다이어그램으로 표현한다
10_UML의 사용법 Ⅲ - 비객체 지향을 표현한다
11_유스케이스 다이어그램으로 컴퓨터에 맡겨지는 일을 표현한다
12_일의 흐름을 액티비티 다이어그램으로 표현한다
13_상태의 변화를 스테이트 머신 다이어그램으로 표현한다
14_자연 언어와 컴퓨터용 언어의 결점을 보완해 주는 「언어」

Chapter 09 현실 세계와 소프트웨어의 차이를 메워줄 수 있는 모델링
01_현실 세계와 소프트웨어에는 차이가 있다
02_주특기는 「정해진 일」과 「기억하는 일」
03_업무 분석, 요구 정의 및 설계로 차이를 메운다
04_모델링은 3단계를 원활히 진행시키기 위한 기술
05_어플리케이션에 따라 모델링은 변한다
06_비즈니스 어플리케이션은 현실의 사건을 기록한다
07_도서관의 대출 업무 그 자체를 모델링한다
08_도서관 업무를 유스케이스 다이어그램으로 표현한다
09_도서관 시스템의 정보를 개념 모델로 표현한다
10_비즈니스 어플리케이션에서는 데이터만이 이음새 없다
11_임베디드 소프트웨어는 현실 세계의 일을 바꾸어 둔다
12_임베디드 소프트웨어에서는 장치의 연구 개발이 중요하다
13_전자동으로 동작하는 모습을 스테이트 머신 다이어그램으로 표현한다
14_임베디드 소프트웨어는 단지 단조로운 일을 실행한다
15_모델링에는 소프트웨어 개발의 묘미가 있다

Chapter 10 의인화해서 역할을 분담시키는 객체 지향 설계
01_설계를 대상으로 하는 범위는 넓고 깊다
02_실행 효율보다도 유지 보수성과 재사용성이 중시되는 시대
03_설계 목표 Ⅰ- 중복을 배제한다
04_설계 목표 Ⅱ - 구성품의 독립성을 높여라
05_구성품의 독립성을 높이는 비결
06_설계 목표 Ⅲ - 의존 관계를 순환시키지 않는다
07_객체 지향 설계의 감각은 의인화와 역할 분담
08_역할이 분담된 소프트웨어가 만드는 기묘한 세계

Chapter 11 객체 지향으로부터 생겨난 유연한 개발 프로세스
01_기술과 노하우만으로는 소프트웨어 개발에 성공하지 못한다
02_작업 순서와 산출물을 체계적으로 종합한 개발 프로세스
03_변경을 억제하는 폭포수형 개발 프로세스
04_폭포수형 개발 프로세스의 한계
05_변화에 유연하게 대응하기 위한 반복형 개발 프로세스
06_개발을 시간으로 구분해서 관리하는 RUP
07_많은 금기 사항을 깬 XP
08_우수한 소프트웨어를 재빠르게 만들기 위한 「애자일」 선언
09_유연한 개발 프로세스는 객체 지향으로부터 태어났다
10_현재 개발 프로세스의 결정판은 존재하지 않는다
[컬럼] 옛날에는 허용되지 않은 XP

Chapter 12 객체 지향을 자유 자재로 구사하자
01_객체 지향이라는 강력한 개념이 원동력
02_시대가 객체 지향에 따라붙었다
03_객체 지향은 붐으로 끝나지 않는다
04_객체 지향 방법을 자유 자재로 구사하자
05_지적인 소프트웨어 개발을 즐기자