Transcript 리팩토링_및_디자인패턴_개요_20140928

정금호
[email protected]
리팩토링 및 디자인패턴 개요
정금호
 소프트웨어 개발 경력 30년 (2014년 기준)
 아마추어 13년 + 프로페셔널 17년(…ing)
 개발 가능 언어 및 개발 도구
 C/C++/JAVA/RUBY/ASP/JSP/NODE.JS/…
 MSVS/DELPHI/XCODE/ECLIPSE/GCC/VIM/…
 WINDOWS/LINUX/WIN-CE/ANDROID/IOS/…
 수행 프로젝트
 상용 프로젝트 수백건 (App/게임/서비스) 수행
 자체 솔루션,서비스/SI 프로젝트 구분 없이 수행
소프트웨어 개발
SOFTWARE DEVELOPMENT
하드웨어(hardware)
 컴퓨터의 모든 물리적 부품
 입력, 연산, 제어, 기억, 출력 등의 기능 수행
하드웨어
소프트웨어(software)
 저장장치에 저장된 특정한 목적의 하나 또
는 다수의 컴퓨터 프로그램
 컴퓨터 하드웨어에 직접 명령어를 주거나
다른 소프트웨어에 입력을 제공함으로써,
그것이 수행하도록 구현된 기능
소프트웨어 개발
 소프트웨어는 프로그래밍 언어와 개발 도구
를 사용하여 제작
 컴파일러, 링커 only
 통합개발환경 (IDE) : 컴파일러, 링커, 편집기, 디
버거 등 포함
프로그래밍 언어
 C 언어
 C++
 C#
 Java
개발 도구
 Microsoft Visual Studio
 Borland Enterprise Studio
 Xcode
 Eclipse
 GCC
소프트웨어 개발 방법론
 1970년대 – 구조적 프로그래밍
 1990년대
 “객체지향 프로그래밍” 주류로 자리잡음
 “스크럼” 사용 (1990년대 후반)
 2000년대
 익스트림 프로그래밍 사용 (1999년)
 애자일 개념 제창 및 적용 (2005년)
객체 지향 프로그래밍
 OOP : Object-Oriented Programming
 컴퓨터 프로그램을 명령어 목록에서 보는
시각에서 벗어난 새로운 패러다임
 프로그램을 여러 개의 독립 단위(객체,
Object)의 모임으로 바라봄
객체 지향 프로그래밍
 프로그램을 유연하고 변경이 용이하게 만듦
 대규모 소프트웨어 개발에 사용
 프로그래밍을 배우기 쉬움
 소프트웨어 개발과 보수를 용이하게 만듦
 보다 직관적인 코드 분석을 가능하게 함
객체 지향 언어 구성 요소
 Class
 같은 종류의 집단에 속하는 속성(attribute)과 행
위(behavior)를 정의한 것
 사용자 정의 데이터 형 (user define data type)
 Object : Class의 instance(메모리상 할당됨)
 Method : Object의 속성을 조작함
객체 지향 언어 특징
 자료 추상화 : 캡슐화
 상속 : 단일 상속, 다중 상속
 다형성 : 오버라이딩, 오버로딩
 바인딩 : 정적바인딩, 동적바인딩
객체 지향 언어
 C++
 C#
 Java
 Object Pascal, Delphi
 Python
 Perl
 Ruby
 Action Script
객체 지향 프로그래밍 단점
 느린 개발 속도
 처리하고자 하는 업무에 대한 잘못된 이해 또는
분석이 프로그램 구조 자체에 영향을 미침
 초기 설계에 많은 시간이 소모됨
 느린 실행 속도
 추상화에는 상대적으로 많은 컴퓨팅 파워가 소
모됨
객체 지향 프로그래밍 단점
 클래스 상속 문제
 상위 클래스가 기능의 추가/변경 및 디버깅 등으
로 인해 변화가 생겼을 때, 하위 클래스가 정상
동작할지를 예측하기 힘듦
 하위 클래스는 반드시 상위 클래스의 공개된 기
능을 제공해야 하므로 하위 클래스에서 추가된
기능과 더해져서 기능이 많아지고 복잡해짐
 상위 클래스에서 파생된 많은 클래스들이 생길
수 있는데, 규모가 커질수록 다양한 클래스가 존
재할 수 있기 때문에 일관성 있게 만들지 않으면
이해하고 사용하기 힘들어짐
UML
 통합 모델링 언어 (Unified Modeling
Language)
 시스템을 시각화하거나 시스템의 사양이나
설계를 문서화하기 위한 표현 방법
 소프트웨어 공학에서 사용되는 표준화된 범
용 모델링 언어
UML 특징
 UML 자체는 개발 방법이 아니지만 객체 지
향 소프트웨어 개발 방법론과 잘 어울리도
록 설계됨
 UML을 기반으로 한 개발 방법론인
RUP(Rational Unified Process) 등이 만들어
지기도 함
모델
 UML의 그래픽 요소는 다이어그램을 그리는 용
도
 다이어그램은 시스템을 여러가지 시각에서 볼
수 있는 뷰(View)를 제공
 뷰의 집합 = 모델
 UML 모델은 시스템 자체의 “목적 행동”을 설명
하는 언어 (시스템 구현 방법을 설명하는 수단
은 아님)
클래스 다이어그램 (Class
Diagram)
 클래스, 인스턴스, 인터페이스 등의 정적인
관계를 표현
 대부분의 사물은 자신만의 속성과 일정한
행동 수단을 지님
시퀀스 다이어그램 (Sequence
Diagram)
 프로그램이 작동할 때 어떤 메소드가 어떤
순서로 실행되는가, 어떤 추상 클래스가 어
떤 순서로 실행되는가를 표현
 클래스 다이어그램이 정적인 관계를 표현한
다면, 시퀀스 다이어그램은 동적인 관계를
표현함
소프트웨어 프로젝트
SOFTWARE PROJECT
소프트웨어 개발의 특징
 소프트웨어 개발은 공학적 개념과 비공학적
인 개념이 혼재함
 개발 기술만으로 성공적인 소프트웨어 개발
은 어려움
 비즈니스 영역의 문제와 전략의 이해 및 요
구 사항 도출이 어려움
소프트웨어 프로젝트 여건
 IT 기반의 기술 융합/복합으로 고도화된 소
프트웨어 개발 환경
 기술적 고도화, 복잡화로 인한 소프트웨어 개발
수요와 사용자 요구 증대
 소프트웨어의 규모, 복잡도 및 비용 증가와
시장 적시성 요구됨
소프트웨어 프로젝트 유형
 프로젝트 성공 요인은 참여자들의 만족이다?
소프트웨어 프로젝트 문제 원인
 기본적인 문제
 초기 요구 사항 분석 및 설계 문제, 필요한 개발 스킬
에 맞는 개발자의 부족, 잦은 개발자 교체
 관리적인 문제
 비용, 일정, 자원 등에 대한 잘못된 예측, 부적절한 감
시 및 감독, 변경에 대한 관리 부재
 환경적인 문제
 불충분한 개발 도구 및 시설, 부적절한 시스템 엔지
니어링, 외부 자원 의존
국내 소프트웨어 개발 환경 현황
 소프트웨어 개발 기술
 개발 프로세스에 공학적 방법과 비공학적 관행
혼재 (낮은 생산성과 품질)
 소프트웨어 공학 기술에 대한 이해 없이 프로젝
트 수행
 소프트웨어 개발 인력
 초급 개발 인력 위주의 양적 공급 (중급/고급인
력 부족)
 일부 개인의 역량에 의존하는 개발 문화
국내 소프트웨어 개발 환경 현황
 소프트웨어 개발 문화
 코딩 중심의 개발 조직 : 개발 프로세스 미정립
 낮은 소프트웨어 품질 : 해외 진출 걸림돌
 사업 환경의 후진성 : 공공 프로젝트 저가 경쟁
 경영진/현업의 IT 전략 수립이나 의사 결정 시에
참여 수준 낮음
 소프트웨어에 대한 비중 낮음 : 소프트웨어보다
는 하드웨어에 대한 투자가 지나치게 높음
소프트웨어 프로젝트 성공률
 출처 : “Crisical success factors for software
projects : comparative study” by Nasir,
Sahibuddin
 1994년부터 2008년까지 Chaos Report에서
발표된 프로젝트 성과
소프트웨어 프로젝트 성공 요인
 명확한 요구 사항 및 명세
 명확한 목적/목표/범위
 현실적인 일정
 효과적인 프로젝트 기술 및 방법
애자일(agile) 개발 방법
 신속하고 효율적인 개발이 가능한 다양한
개발 방법론
 불필요한 작업 부담 줄이면서 변화에 쉽게
대응하여 고객의 입장에 초점을 맞춤
 다양한 사용자의 요구와 제품 수명 주기가
짧아진 변화에 적응 가능함
애자일 개발 방법론 특징
 사회 공학적인 측면으로 소프트웨어 개발에
대해서 접근함
 상소 의사 소통을 중시하는 “사람 중심의 개
발 방법론”
 어떠한 방법으로 팀을 효율적으로 운영할 것인
가?
 어떻게 구성원 들을 고무시키고 협동할 수 있도
록 만들 것인가?
애자일 개발 방법론
 익스트림 프로그래밍 (XP)
 스크럼 (Scrum)
 린 소프트웨어 개발
 기능 주도 개발, 테스트 주도 개발
 크리스탈 방법론
Extreame Programming (XP)
 고객 만족에 포커스를 맞춰서 고객의 요구
변화에 부응할 수 있도록 함
 요구 사항이 많거나 잦은 변화가 예상되는
프로젝트를 진행 할 때 활용 가능
 수시로 고객과 팀원들 사이에 의사 소통을
하고, 가능한 한 빨리 고객에게 결과물을 전
달하게 만듦
XP 권장 규칙
 모든 일을 단순하게 설계한다
 정규 일과 시간에만 작업한다
 조금씩 자주 결과물을 발표한다
 짧은 배포 주기에 맞추어 현실적인 작업 계
획을 만든다
 스펙에 없는 것은 절대 추가하지 않는다
 사이클을 반복하여 개발한다
 수시로 코드를 개선시킨다(refactoring)
XP 권장 규칙
 코딩 표준을 정하고 철저하게 준수한다
 테스트 코드를 먼저 만든다 (TFD)
 모든 테스트를 통과하지 않으면 발표하지
않는다
 짝 프로그래밍을 한다
 개발팀 내에 사용자가 상주한다 (고객 위주
프로그래밍)
 지속적으로 통합한다
소프트웨어 프로젝트 성공률
 RUP과 같은 반복 개발(Iterative) 방법과
Agile이 70%에 가까운 성공률을 보임
출처 : Scott Amber 홈페이지 (2011년 분석결과)
소프트웨어 프로젝트 성공률
 품질, 가치, 수익(ROI), 일정 별로 구분하여
평가했을 때 다른 방법에 비하여 모든 요인
에서 애자일이 좋은 결과를 보임
리팩토링
REFACTORING
리팩토링이란?
 켄트 벡, 존 브랜트, 빌 옵다이크, 돈 로버츠
등의 개발자들이 연구한 결과를 바탕으로
정리된 ‘개발 경험’
 ‘마틴 파울러’가 정리하여 책으로 출간
리팩토링 유래
 초반부터 깔끔한 코드를 작성하는 것은 불
가능하다
 깔끔한 코드가 복잡하고 정신 없는 코드보
다 유지보수가 용이하다
 최소한의 시간을 투자해서 자신의 코드를
정리하는 것이 이익이다
리팩토링(refactoring)
 겉으로 드러나는 기능은 그대로 둔 채, 알아
보기 쉽고 수정하기 간편하게 소프트웨어
내부를 수정하는 작업
 사용자가 보는 외부 화면은 그대로 두면서
내부 논리나 구조를 바꾸고 개선하는 유지
보수 행위
리팩토링
 결과의 변경 없이 코드의 구조를 재조정
 주로 가독성을 높이고 유지보수를 용이하게
함
 버그를 없애거나 새로운 기능 추가가 아님
리팩토링 필요성
 소프트웨어 설계 개선
 소프트웨어 이해도 개선
 버그 원인 추적 용이
 프로그래밍 속도 개선
리팩토링 필요 시점
 같은 작업의 삼진 아웃 때
 기능 추가할 때
 버그 수정할 때
 코드 검수할 때
리팩토링 전제 조건
 리팩토링 시에는 반드시 견고한 테스트가
전제되어야 함
 리팩토링 자동화 도구를 사용하더라도 테스
트는 필수
 모든 테스트를 완전히 자동화하고 결과를
자체적으로 검사하게 해야 함
리팩토링 효용성
 프로그램 코드를 알아보기 쉽게 작성
 모든 로직을 한곳으로 집중 (중복 제거)
 기존 기능 건드리지 않고 확장 가능
 최대한 간결한 조건문 구조
리팩토링 접근 방법
 “대부분의 프로그래머가 품질에 대해 압박을
받는다지만 일정에 대한 압박만 못하다. 반론
이 있을지도 모르겠지만, 이렇게 일정이 빠듯
할 땐 리팩토링 얘길 꺼내지 말고 몰래 실시하
자.”
 “소프트웨어 개발자의 임무는 전무가로서 효
과적인 소프트웨어를 최대한 신속히 제작하기
만 하면 된다. 일정에 쫒기는 팀장은 개발자에
게 최대한의 속도로 작업하길 바라기 마련인데
어떻게 하든 내 소관이다.”
데이터베이스 리팩토링 이슈
 문제 :
 어플리케이션과 결합된 데이터 스키마가 존재
함
 데이터 이전 시 발생하는 리스크가 있음
 대안 :
 객체 모델과 데이터베이스 모델 사이에 별도의
소프트웨어 계층을 둠
 한 모델을 수정할 때 다른 모델은 수정할 필요 없
이 그저 중개 기능만 수정하면 됨 (유연성 발생)
인터페이스 리팩토링 이슈
 문제 :
 수정하고자 하는 인터페이스를 호출하는 부분
을 모두 찾아서 수정할 수 없는 경우가 있음
 대안 :
 배포된 인터페이스를 수정해야 할 경우, 기존 인
터페이스와 새 인터페이스를 모두 그대로 유지
시킴
 꼭 필요할 때가 아니면 인터페이스를 published
타입으로 만들지 않는 것이 좋음
설계 변경과 리팩토링
 문제 :
 설계 자체에 오류가 있거나 설계에 대한 결정이
변경되었을 때, 또는 수정하기 힘들 것 같은 민감
한 부분이라고 판단됨
 사례 :
 프레임워크 선택이나 연동 기술 선택 같은 특정
설계적 판단을 배제한 채 리팩토링을 진행하는
것은 어렵기는 해도 가능함
리팩토링 하면 안 되는 시점
 코드를 새로 작성해야 할 때
 코드가 제대로 실행되지 않을 때
 납기가 임박했을 때
리팩토링과 설계
 “리팩토링을 실시하면 유연성을 낮추지 않
고도 더 간결한 설계가 가능해진다. 그래서
설계 과정이 쉬워지고 스트레스도 줄어든
다.”
 “잘 돌아갈 정도로만 제일 단순한 솔루션을
구축하자. 유연하고 복잡한 설계가 필요한
상황은 거의 없으니 말이다.”
리팩토링과 성능
 “리펙토링을 실시하면 분명 소프트웨어는
더 느려지지만, 소프트웨어 성능을 더 간단
히 조절할 수 있다. 소프트웨어 성능을 올리
려면 먼저 소프트웨어를 튜닝 가능하게 만
들어 놓고 나중에 충분한 속도가 나오게 튜
닝 하는 것이다.”
리팩토링 단서
REFACTORING CLUES
중복 코드 (Duplicated Code)
 한 클래스의 두 메서드 안에 같은 코드가 들
어있다
 한 클래스의 두 하위 클래스에 같은 코드가
들어 있다
 서로 상관 없는 두 클래스 안에 중복된 코드
가 있다
장황한 메서드 (Long Method)
 메서드의 기능을 한눈에 알 수 있는 메서드
명을 사용하면 그 메서드 안의 코드를 분석
하지 않아도 됨
 최적의 상태로 장수하는 객체 프로그램은
공통적으로 메서드 길이가 짧음
방대한 클래스 (Large Class)
 기능이 많은 클래스에는 많은 인스턴스 변
수가 있고, 인스턴스 변수가 많으면 중복 코
드가 존재할 확률이 높다
 코드 분량이 많은 클래스에도 중복 코드가
많이 있기 마련이다
과다한 매개 변수 (Long
Parameter List)
 객체 지향 프로그래밍 이전에는 전역 데이
터 사용을 피하기 위해 많은 매개 변수를 사
용해왔음
 객체를 사용할 때는 메서드에 필요한 모든
데이터를 전달하는 게 아니라 모든 데이터
를 전달할 수 있는 메서드만 전달하면 됨 (메
서드가 필요로 하는 모든 데이터는 그 메서
드가 속한 클래스에 존재하기 때문)
산발적인 수정 (Divergent
Change)
 한 클래스가 다양한 원인 때문에 다양한 방
식으로 자주 수정될 때 발생함
 소프트웨어에 대한 수정을 할 때, 손쉽게 특
정 위치로 가서 수정하지 못할 경우에는 의
심할 수 있음
 하나의 클래스를 여러 개의 변경 객체로 분
리하면, 한 종류의 수정에 의해서만 변경됨
산재된 기능 (Shotgun Surgery)
 수정할 때마다 여러 클래스에서 수많은 부
분을 수정해야 하는 경우
 수정할 부분이 많으면 찾기 힘들고 수정해
야 하는 부분을 놓칠 수 있음
 수정해야 할 부분을 하나의 클래스 안에 넣
도록 개선 필요
잘못된 소속 (Feature Envy)
 어떤 메서드가 자신이 속하지 않은 클래스
에 더 많이 접근할 경우
 한 메서드가 여러 클래스에 들어있는 기능
을 이용할 때도 많기 때문에 개선이 쉽지 않
음  접근하는 데이터가 가장 많은 클래스
를 선택함
데이터 뭉치 (Data Clumps)
 두 클래스에 있는 인스턴스 변수나 여러 메
서드에 들어있는 매개변수처럼, 동일한 3~4
개의 데이터 항목이 여러 위치에 몰려 있는
경우엔 객체화
 매개 변수가 적어져서 메서드 호출이 간결
해지고 성능이 개선될 여지도 있음
강박적 기본 타입 사용
(Primitive Obsession)
 객체의 주요 장점 : 기본 타입 클래스와 응용
클래스 간의 경계를 허물 수 있음  언어에
내장된 기본 타입과 구별하기 힘든 작은 클
래스 작성이 용이
 예) 자바의 wrapper 클래스, String 클래스,
Date 클래스
Switch문 (Switch Statements)
 Switch문의 단점 : 반드시 중복이 생김  같
은 switch문에 새 코드 행을 추가하려면 모
든 switch문을 찾아서 수정해주어야 함
 객체 지향의 “다형성”을 이용하면 switch문
을 대체할 수 있음
평행 상속 계층 (Paraled
Inheritance Hierarchies)
 “산재된 기능”의 특수한 케이스
 한 클래스의 하위 클래스를 만들 때마다 다
른 클래스의 하위 클래스도 만들어야 하는
경우 (서로 다른 두 상속 계층의 클래스명 접
두어가 같을 수 있음)
 중복된 코드 제거를 위해서는 한 상속 계층
의 인스턴스가 다른 계층의 인스턴스를 참
조하면 됨
직무 유기 클래스 (Lazy Class)
 하나의 클래스를 만들 때마다 비용이 추가
되기 때문에, 비용만큼의 기능을 수행하지
못하는 비효율적 클래스는 제거해야 함
 리팩토링으로 기능이 축소된 클래스나, 쓸
모 없어진 클래스 등이 해당됨
막연한 범용 코드 (Speculative
Generality)
 막연한 생각에 아직은 필요 없는 기능을 수
행하고자 온갖 호출과 case 문을 구현할 경
우, 코드를 이해하기 힘들고 유지보수가 어
려워짐
 메서드나 클래스가 오직 테스트 케이스에서
만 사용될 때에도, 그것과 그것을 실행하는
테스트 케이스를 삭제해야 함
임시 필드 (Temporary Field)
 어떤 객체 안에 인스턴스 변수가 특정 상황
에서만 할당되는 경우
 수많은 매개변수를 전달하는 것이 번거로워
서 매개변수를 직접 필드에 대입함  이 인
스턴스 변수는 해당 알고리즘이 실행되는
동안에만 효력이 있기 때문에, 다른 경우에
는 코드를 복잡하게 만듦
메시지 체인 (Message Chain)
 클라이언트가 한 객체에 제 2의 객체를 요구
하면, 제 2의 객체가 제 3의 객체를 요청하고,
제3의 객체가 제 4의 객체를 요청하는 식으
로 연쇄적 요청이 발생하는 경우
 메시지가 왕래하는 체제의 관계 수정이 필
요할 경우, 클라이언트도 수정해야 함
과잉 중개 메서드 (Middle Man)
 객체의 주요 특징인 “캡슐화”는 내부의 처리
를 외부에서 볼 수 없게 은폐하는데, 이때 대
부분 “위임”을 하게됨
 어떤 클래스의 메서드들 중에 절반 이상의
메서드가 기능을 다른 메서드에 위임하고
있는 경우
지나친 관여 (Inapporopriate
Intimacy)
 클래스 간의 관계가 지나치게 밀접하여 서
로의 private 영역까지 과도하게 접근하는
경우  엄격하고 절제된 규칙에 따라 관리
 상속으로 인해 지나친 관여가 발생하는 경
우 (하위 클래스는 항상 상위 클래스가 공개
하는 것보다 많은 데이터를 필요로 함)
인터페이스가 다른 대용 클래스
(Alternative Classes with Different Interfaces)
 기능은 같은데 시그니처가 다른 메서드가
존재할 경우
 메서드명을 변경하거나 해당 클래스로 이동
시킬 필요 있음
미흡한 라이브러리 클래스
(Incomplete Library Class)
 객체 재사용에 대한 맹신 때문에, 프로그래
머가 라이브러리 클래스에 대한 의존도가
높음
 라이브러리 클래스를 원하는 기능을 수행하
게 수정하는 것은 불가능함
데이터 클래스 (Data Class)
 데이터 클래스는 데이터 보관만 담당하고,
대부분의 연산은 다른 클래스가 수행하기
때문에 public 필드일 확률이 높음
 캡슐화를 소홀히 한 부분에 대해서 즉각적
인 조치가 필요함
방치된 상속물 (Refused
Bequest)
 상속받은 부모 클래스의 메서드와 데이터를
하위 클래스에서 더 이상 사용하지 않는 경
우
 잘못된 계층구조가 원인일 수 있으나, 심각
하지 않은 경우가 대부분이라 리팩토링이
별로 필요치 않음
불필요한 주석 (Comments)
 엄청난 양의 주석이 달린 코드는 코드의 잘
못된 부분을 가리기 위해 주석을 사용하는
경우가 있음
 리팩토링을 통해서 주석이 존재하지 않아도
되는지 확인이 필요함
디자인 패턴
DESIGN PATTERN
디자인 패턴이란?
 GoF : the Gang of Four
 Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides 등 4명의 개발자(과학 연구자?)
 Design Pattern
 GoF가 정리한 개발자의 ‘경험’이나 ‘내적인 축적’
디자인 패턴 정의
 프로그램 개발에서 자주 나타나는 과제를
해결하기 위한 방법 중 하나
 과거의 소프트웨어 개발 과정에서 발견된
설계의 노하우를 축적하여 이름을 붙이고
이후에 재이용하기 좋은 형태로 특정의 규
약을 묶어서 정리한 것
디자인 패턴 정의
 알고리즘과 같이 프로그램 코드로 바로 변
환될 수 있는 형태는 아니지만, 특정한 상황
에서 구조적인 문제를 해결하는 방식을 설
명해줌
디자인 패턴 개념
 “디자인 패턴” != “클래스 라이브러리”
 클래스 라이브러리보다 더 일반적인 개념
 클래스 라이브러리 = 부품이 되는 프로그램
 디자인 패턴 = 부품이 어떻게 조립되어 있고,
각각의 부품이 어떻게 관련해서 큰 기능을
발휘하는지를 표현
클래스 라이브러리 안에서 디자
인 패턴이 사용된다
 Java의 표준적인 클래스 라이브러리 안에는
디자인 패턴이 많이 활용 됨
 디자인 패턴을 이용하고 있으면 클래스 라
이브러리의 역할을 이해하는데 도움이 됨
프로그램은 완성품이 아니다
 디자인 패턴의 목표 중 하나는 프로그램의
재이용을 가능케 하는 것
 프로그램을 어떻게 “부품”으로써 재이용할
수 있는가?
 프로그램을 ‘완성품’이 아니라 앞으로 ‘기능
을 확장해 가는 것’, ‘변경할 수 있는 것’임
디자인 패턴에서의 “역할”
 디자인 패턴마다 클래스나 인터페이스에 각
자의 역할이 주어짐  역할을 이해하지 못
하면 전체의 패턴을 이해할 수 없음
 동일한 패턴이라면 클래스 이름이 다르더라
도 클래스에 상응하는 역할이 주어짐
디자인 패턴 적용 규칙
 구현 클래스가 아니라 인터페이스를 가지고
프로그래밍한다
 인터페이스를 바탕으로 하는 클래스 호출
 상속(Inheritance)이 아니라 Delegation을 사
용한다
 delegation을 통해 런타임의 행위를 변경
 의존도(Coupling)를 최소화함으로써 추후의
변화를 국부화한다
디자인 패턴 종류
 Iterator – 순서대로 지정해서 처리하기
 Adapter – 바꿔서 재이용하기
 Template Method – 하위 클래스에서 구체적
으로 처리하기
 Factory Method – 하위 클래스에서 인스턴
스 만들기
 Singleton – 인스턴스를 한 개만 만들기
 Prototype – 복사해서 인스턴스 만들기
디자인 패턴 종류
 Builder – 복잡한 인스턴스 조립하기
 Abstract Factory - 관련 부품을 조합해서 제





품 만들기
Bridge – 기능 계층과 구현 계층 분리하기
Strategy – 알고리즘을 모두 바꾸기
Composite – 그릇과 내용물을 동일시 하기
Decorator – 장식과 내용물을 동일시하기
Visitor – 데이터 구조를 돌아다니면서 처리
하기
디자인 패턴 종류
 Chain of Responsibility – 책임 떠넘기기
 Façade – 단순한 창구
 Mediator – 중개인을 통해서 처리하기
 Observer – 상태의 변화를 알려주기
 Memento – 상태를 저장하기
 State – 상태를 클래스로 표현하기
 Flyweight – 동일한 것을 공유해서 낭비 없애
기
디자인 패턴 종류
 Proxy – 필요해지면 만들기
 Command – 명령을 클래스로 하기
 Interpreter – 문법 규칙을 클래스로 표현하
기