자바 객체지향 디자인 패턴

CHAPTER 1 객체지향 모델링
__1.1 모델링
__1.2 UML
__1.3 클래스 다이어그램
____1.3.1 클래스
____1.3.2 관계
__체크포인트 해설
__연습문제

CHAPTER 2 객체지향 원리
__2.1 추상화
__2.2 캡슐화
__2.3 일반화 관계
____2.3.1 일반화는 또 다른 캡슐화
____2.3.2 일반화 관계와 위임
____2.3.3 집합론 관점으로 본 일반화 관계
__2.4 다형성
__2.5 피터 코드의 상속 규칙
__체크포인트 해설
__연습문제

CHAPTER 3 SOLID 원칙
__3.1 단일 책임 원칙
____3.1.1 책임의 의미
____3.1.2 변경
____3.1.3 책임 분리
____3.1.4 산탄총 수술
____3.1.5 관심지향 프로그래밍과 횡단 관심 문제
__3.2 개방-폐쇄 원칙
__3.3 리스코프 치환 원칙
__3.4 의존 역전 원칙
__3.5 인터페이스 분리 원칙
__체크포인트 해설
__연습문제

CHAPTER 4 디자인 패턴
__4.1 디자인 패턴의 이해
__4.2 GoF 디자인 패턴
__4.3 UML과 디자인 패턴
____4.3.1 컬레보레이션
____4.3.2 순차 다이어그램
____4.3.3 순차 다이어그램과 클래스 다이어그램의 관계
__체크포인트 해설
__연습문제

CHAPTER 5 스트래티지 패턴
__5.1 로봇 만들기
__5.2 문제점
____5.2.1 기존 로봇의 공격과 이동 방법을 수정하는 경우
____5.2.2 새로운 로봇에 공격/이동 방법을 추가/수정하는 경우
__5.3 해결책
__5.4 스트래티지 패턴
__연습문제

CHAPTER 6 싱글턴 패턴
__6.1 프린터 관리자 만들기
__6.2 문제점
__6.3 해결책
__6.4 싱글턴 패턴
__6.5 싱글턴 패턴과 정적 클래스
__연습문제

CHAPTER 7 스테이트 패턴
__7.1 상태 머신 다이어그램
__7.2 형광등 만들기
__7.3 문제점
__7.4 해결책
__7.5 스테이트 패턴
__연습문제

CHAPTER 8 커맨드 패턴
__8.1 만능 버튼 만들기
__8.2 문제점235
____8.2.1 버튼을 눌렀을 때 다른 기능을 실행하는 경우
____8.2.2 버튼을 누르는 동작에 따라 다른 기능을 실행하는 경우
__8.3 해결책
__8.4 커맨드 패턴
__연습문제

CHAPTER 9 옵서버 패턴
__9.1 여러 가지 방식으로 성적 출력하기
__9.2 문제점
____9.2.1 성적을 다른 형태로 출력하는 경우
____9.2.2 동시 혹은 순차적으로 성적을 출력하는 경우
__9.3 해결책
__9.4 옵서버 패턴
__연습문제

CHAPTER 10 데커레이터 패턴
__10.1 도로 표시 방법 조합하기
__10.2 문제점
____10.2.1 또다른 도로 표시 기능을 추가로 구현하는 경우
____10.2.2 여러 가지 추가 기능을 조합해야 하는 경우
__10.3 해결책
__10.4 데커레이터 패턴
__연습문제

CHAPTER 11 템플릿 메서드 패턴
__11.1 여러 회사의 모터 지원하기
__11.2 문제점
__11.3 해결책
__11.4 템플릿 메서드 패턴
__연습문제

CHAPTER 12 팩토리 메서드 패턴
__12.1 여러 가지 방식의 엘리베이터 스케줄링 방법 지원하기
__12.2 문제점
__12.3 해결책
__12.4 팩토리 메서드 패턴
__연습문제

CHAPTER 13 추상 팩토리 패턴
__13.1 엘리베이터 부품 업체 변경하기
__13.2 문제점348
____13.2.1 다른 제조 업체의 부품을 사용해야 하는 경우
____13.2.2 새로운 제조 업체의 부품을 지원해야 하는 경우
__13.3 해결책
__13.4 추상 팩토리 패턴
__연습문제

CHAPTER 14 컴퍼지트 패턴
__14.1 컴퓨터에 추가 장치 지원하기
__14.2 문제점
__14.3 해결책
__14.4 컴퍼지트 패턴
__연습문제

연습문제 정답 및 해설

찾아보기

[지은이 서문]

거의 1년에 걸친 작업을 마치고 출판사로부터 책의 서문을 부탁받았을 때 1초의 망설임도 없이 서문에 꼭 넣어야겠다는 단어가 떠올랐습니다. 바로 '변화'입니다. 이 단어의 의미를 이 책에서 꼭 설명하고 싶었습니다. 만약 이 책의 마지막 쪽을 덮고 (물론 그 전이라도) '변화'의 의미를 이해했다면 이 책을 쓴 목적을 이루었다고 해도 무방하리라 생각합니다.

'디자인 패턴'을 학생들에게 가르친 지가 얼마나 되었는지 알아보려고 학교 종합 정보 시스템에 접속해봤습니다. 2006년부터 강의했더군요. 벌써 8년이란 세월이 흘렸네요. 그러나 강의를 하면 할수록 진흙 속에 숨어 있는 진주를 찾는 기분이었습니다. 작년에는 보이지 않던 것이 올해에는 보이는 그런 기분 말이죠.

항상 제가 수업 첫 시간에 학생들에게 던지는 질문이 있습니다.

'클래스'가 무엇인가요?

대부분의 학생은 이 질문에 '멤버 변수와 메서드가 포함된 무엇'이라고 답합니다. 왜냐하면 디자인 패턴을 수강하는 거의 모든 학생이 C++나 자바 같은 객체지향 프로그래밍 언어에 대한 지식이 있기 때문입니다. 이와 같은 언어로 프로그램을 작성할 때 가장 많이 사용하는 것이 클래스일 겁니다. 또한 학생 스스로 작성했던 클래스 안에 속성을 표현하려고 멤버 변수를 사용하고, 행위를 표현하려고 메서드를 사용하므로 클래스를 이처럼 정의할 것입니다. 물론 이 대답이 잘못된 것은 아닙니다. 그러나 속성과 행위가 합쳐진 그 무엇으로 클래스를 바라봤을 때는 꼭 그렇지는 않습니다. 실제 현업이나 그 전에 경험하지 못한 도메인에서 프로그래밍할 때 어떤 것을 클래스로 만들어야 하는지가 매우 어려울 수 있기 때문이죠.

프로그래밍을 배우는 사람이라면 누구라도 프로그래밍을 잘하고 싶을 것입니다. 제 경험에 미루어 프로그래밍을 잘하는 가장 좋은 방법은 다른 사람이 만든 프로그램을 열심히 살펴보는 것입니다. 물론 전제가 있습니다. 경험이 많고 실력 있는 프로그래머가 작성한 좋은 프로그램을 살펴봐야 합니다. 그러나 여기에 함정이 있습니다. 경험이 많고 실력이 있다고 해서 항상 좋은 프로그램을 만드는 것은 아닙니다. 좋은 프로그램이 만들어지기까지는 여러 조건이 충족되어야 하지만 가장 중요한 한 가지는 비슷한 문제에 바로 적용할 수 있어야 한다는 겁니다. 이런 경우 디자인 패턴은 수십 년 동안 자주 반복되던 문제가 발생한 상황에서 재사용할 수 있는 해결책을 제공합니다.

이 책에서는 지금까지 소개된 모든 디자인 패턴을 다루지는 않습니다. 책의 전반부에 해당하는 1장부터 3장까지는 디자인 패턴을 이해하는 데 필요한 객체지향의 기본 개념을 다루고 실제 이를 바탕으로 소프트웨어를 설계할 때 지켜야 하는 원칙을 설명합니다. 반드시 알아야 하는 UML도 다루었습니다. 4장에서는 디자인 패턴을 간단히 소개하고 5장부터 14장에 걸쳐 가장 기본이 되고 핵심이 되는 10개의 디자인 패턴을 소개했습니다. 만약 이 책에서 소개한 디자인 패턴을 이해하고 실제 프로그래밍에 적용할 수 있다면 소개되지 않은 다른 디자인 패턴을 이해하는 것도 그리 어려운 일은 아닐 거라고 생각합니다.

세상은 변합니다. 변화되지 않은 세상은 죽은 세상일 겁니다. 따라서 기존의 것을 바꾸고 새로운 것을 항상 받아들일 수 있는 준비가 되어 있어야 합니다. 변화를 두려워하면 발전이라는 달콤한 열매를 맛볼 수 없을 겁니다. 이게 세상의 이치입니다. 프로그래밍도 마찬가지입니다. 좋은 프로그램은 항상 변화에 대응할 준비가 되어 있습니다. 이 책을 읽는 독자라면 뭐가 변화되는지에 대해 항상 두 눈을 부릅뜨고 살펴보기 바랍니다. 디자인 패턴은 좋은 프로그램을 만들기 위한 도구입니다. 그러므로 디자인 패턴을 제대로 이해하려면 만들어진 프로그램을 흔들어 보고 어떤 것이 변화되는지를 잘 살펴봐야 합니다.

"클래스는 변화의 기본 단위입니다."

2014. 3_ 정인상, 채흥석