IT CookBook, 쉽게 배우는 소프트웨어 공학

[강의교안 이용 안내]

• 본 강의교안의 저작권은 김치수와 한빛아카데미㈜에 있습니다.

• 이 자료는 강의 보조자료로 제공되는 것으로, 학생들에게 배포되어서는 안 됩니다. 

Chatpter 

05 상위 설계

01 설계의 이해

02 설계의 원리

03 소프트웨어 아키텍처

04 디자인 패턴

요약

연습문제

3/89



소프트웨어 설계 원리를 이해한다

.



소프트웨어 아키텍처를 살펴본다

.



소프트웨어 아키텍처 스타일을 알아본다

.



소프트웨어 디자인 패턴을 살펴본다

.

Section 01 설계의 이해

5/89

1. 설계의 이해

6/89

1-1 설계의 예: 옷본

7/89

1-2 건축 설계 과정

8/89

2. 소프트웨어 설계

 분석 단계



사용자의 요구 사항을 토대로 요구 분석 명세서 작성



개념적이고 추상적

, what(무엇) 관점

 설계 단계



분석 단계에서 파악한 비기능적 요구 사항과 제약 사항 고려 



운영체제

·미들웨어·프레임워크 등의 플랫폼 결정, how(어떻게) 관점

 설계



요구 분석 명세서를 기반으로 어떻게 구축할 것인가를 결정하는 것



설계자

: 다양한 제약 조건을 만족시킬 수 있는 최적의 설계안을 만드는 것이 중요



설계를 평가할 수 있는 기준도 정량적으로 명시

9/89

3. 좋은 설계의 조건

• 요구 분석 명세서의 내용을 설계서에 모두 포함해야 한다

.

• 유지보수가 용이하도록 추적이 가능해야 한다

.

• 변화에 쉽게 적응할 수 있어야 한다

.

• 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 한다

.

• 설계서는 읽기 쉽고

, 이해하기 쉽게 작성해야 한다.

10/89

4. 설계의 종류(1)

11/89

4. 설계의 종류(2)

 상위 설계(예비 설계preliminary design)

• 아키텍처

(구조) 설계 : 시스템의 전체적인 구조

• 데이터 설계 

: 시스템에 필요한 정보를 자료구조와 데이터베이스 설계에 반영

• 시스템 분할 

: 전체 시스템을 여러 개의 서브시스템으로 나눈다.

• 인터페이스 정의 

: 시스템의 구조와 서브시스템들 사이의 인터페이스가 명확히 정의

• UI 설계 : 사용자가 익숙하고 편리하게 사용할 수 있도록 사용자 인터페이스설계

 하위 설계

• 각 모듈의 실제적인 내부를 알고리즘

(pseudo-code) 형태로 표현

• 인터페이스에 대한 설명

, 자료구조, 변수 등에 대한 상세한 정보를 작성

Section 02 설계의 원리

13/89

1. 설계의 원리

14/89

2. 분할과 정복의 원리

 분할과 정복



큰 문제를 소 단위로 나누고 소 단위의 작업을 하나씩 처리하여 전체 일을 끝내는 방법

   (예) 대학의 종합정보시스템: 학사 관리, 회계 관리, 인사 관리 등으로 나눔

         학사 관리

: 수강 관리, 수업 관리, 성적 관리 등으로 나눔

 분할 형태

• 분산 시스템은 클라이언트와 서버로 분할

• 시스템은 여러 서브시스템으로 분할

• 서브시스템은 하나 이상의 패키지로 분할

• 패키지는 여러 클래스로 분할

• 클래스는 여러 메서드로 분할

15/89

3. 추상화의 원리

 추상화abstraction



주어진 문제

(건물 도면)에서 현재의 관심사에 초점을 맞추기 위해, 특정한 목적과 관련된 필수 

정보만 추출하여 강조하고

(전기 배선도, 상하수도 배관도 등) 관련이 없는 세부 사항을 

생략함으로써 본질적인 문제에 집중할 수 있도록 하는 작업

16/89

3-1 도형의 추상화

17/89

3-2 객체지향 설계에서의 추상화

18/89

3-3 추상화의 종류(1)

 과정 추상화procedure abstraction

19/89

3-3 추상화의 종류(2)

 Class의 특징



사용자에게 클래스가 제공할 수 있는 사용법만 알려주고

, 불필요한 데이터와 연산을 감춤 



사용자는 클래스에서 제공하는 연산 기능만 알고 그 연산을 사용하여 데이터 값을 변경

 데이터 추상화data abstraction



대표적인 예

: C++ 언어의 클래스

20/89

3-3 추상화의 종류(3)

 제어 추상화control abstraction

21/89

4. 단계적 분해

 단계적 분해



하향식 설계에서 사용



기능을 점점 작은 단위로 나누어 점차적으로 구체화하는 방법 

22/89

5. 모듈화

 모듈



‘규모가 큰 것을 여러 개로 나눈 조각’



‘소프트웨어 구조를 이루는 기본적인 단위’



‘하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합’



라이브러리 함수

, 그래픽 함수



라이브러리 함수

, 그래픽 함수, 추상화된 자료, subroutine, procedure, object, method

   → 독립 프로그램도 하나의 모듈로 가능

, 함수들도 하나의 모듈로 가능

 모듈의 특징



다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위이다

.



유일한 이름을 가져야 한다

.



독립적으로 컴파일이 가능하다

.



모듈에서 또 다른 모듈을 호출할 수 있다

.



다른 프로그램에서도 모듈을 호출할 수 있다

. 

Section 03 소프트웨어 아키텍처

24/89

1. 소프트웨어 아키텍처

25/89

2. 아키텍처의 특징과 기능(1)

 아키텍처의 정의



구성 요소



구성 요소들 사이의 관계



구성 요소들이 외부에 드러내는 속성



구성 요소들과 주변 환경 사이의 관계



구성 요소들이 제공하는 인터페이스



구성 요소들의 협력 및 조립 방법

 소프트웨어 아키텍처



개발할 소프트웨어 대한 전체적인 구조를 다룬다

.



소프트웨어를 이루고 있는 여러 구성 요소

(서브시스템, 컴포넌트)를 다룬다.



구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지를 정의해야 한다

.



세부 내용보다는 중요한 부분만을 다룬다

.



시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 한다

.

26/89

2. 아키텍처의 특징과 기능(2)

 아키텍처의 설계 시 고려 사항



의사소통 도구로 활용할 수 있어야 한다

.



구현에 대한 제약 사항을 정의해야 한다

.



품질 속성을 결정해야 한다

.



재사용할 수 있게 설계해야 한다

.

 아키텍처의 설계 시 기술 방법



이해하기 쉽게 작성 



명확하게 기술 



표준화된 형식 사용 



문서 버전 명시

27/89

3. 아키텍처의 품질 속성

 품질 요구 사항



시스템이 제공해야 하는 품질 속성의 수준



가능하면 정확한 수치로 제시

 소프트웨어 아키텍처



이해 관계자들의 품질 요구 사항을 반영하여 품질 속성을 결정

28/89

3-1 시스템 품질 속성(1)

 가용성(availability)



시스템이 운용될 수 있는 확률로

, 시스템이 장애 발생 없이 서비스를 제공할 수 있는 능력



가용성을 높이려면

: 하드웨어 이중화처럼 여분의 구성 요소를 포함하도록 설계

 변경 용이성(modifiability)



변경 요구 사항을 받았을 때 쉽게 변경할 수 있는 능력



빈번하게 변경할 가능성이 높은 소프트웨어는 변경 용이성을 고려하여 아키텍처를 결정

 성능(performance)



사용자 요청과 같은 이벤트가 발생했을 때

, 빠르고 적절하게 반응할 수 있는 능력



공유 자원을 어떻게 사용하는지

, 어떤 알고리즘을 사용해 구현하는지 등의 요소와 밀접

29/89

3-1 시스템 품질 속성(2)

 보안성(security)



허용되지 않은 접근에 대응할 수 있는 능력

 사용성(usability)



소프트웨어를 사용할 때 혼란스러워하거나 사용하는 순간에 고민하지 않게 하는 편의성

 테스트 용이성(testability)



사용자가 요구하는 기능을 만족스럽게 잘 수행하고 있는지를 얼마나 쉽고 철저하게 테스트할 수 

있는지를 나타낸다

.

30/89

3-2 비즈니스 품질 속성(1)

 시장 적시성time to market



정해진 날짜에 소프트웨어를 출시해 경쟁력을 높일 수 있는 정도

 비용과 이익cost and benefit



비용을 더 들여 사용하고 효과를 볼 것인지

, 아니면 비용을 절약하는 데 중심을 둘 것인지를 

말한다

.



아키텍처를 설계 시

: 비용을 더 많이 들여 유연한 설계를 할 것인지, 비용을 절감하는데 초점을 

맞출 것인지 판단해야 함

 예상 시스템 수명predicted lifetime of the system



수명이 중요한 경우라면 변경 용이성

, 확장성, 이식성을 더 중요하게 고려

31/89

3-2 비즈니스 품질 속성(2)

 목표 시장targeted market



패키지 소프트웨어

: 기능성 및 다양한 플랫폼에서도 잘 작동되어야 하므로 이식성을 충분히 

고려한 설계 필요

 신규 발매 일정 또는 공개 일정rollout schedule



현재 버전에서는 기본 기능만 제공하고

, 추후에 배포할 차기 버전에서 기능을 추가하여 완성도를 

높일 예정이라면 유연성

flexibility과 확장성을 고려한 설계 필요

 기존 시스템과의 통합integration with legacy system



아키텍처 설계 시 기존 시스템과의 통합 방법을 충분히 고려한 설계 필요

32/89

3-3 아키텍처 품질 속성

 개념적 무결성conceptual integrity



개념적 무결성은 일관성이라고도 함



전체 시스템과 시스템 구성 요소가 일관되도록 아키텍처를 결정

 정확성과 완전성correctness and completeness



사용자가 요구하는 기능을 충족시키는 정도로

, 요구 분석 명세서와 일치하는 정도

 개발 용이성(구축 가능성, buildability)



전체 시스템을 적절한 모듈로 분할한 후 개발 팀에 알맞게 분배하여 개발함으로써 정해진 기간 

내에 완성하고

, 개발 과정 중에도 쉽게 변경할 수 있는 능력

33/89

3-4 이해 관계자별 품질 속성

 발주자 관점



제품 가격

(또는 개발비)이 중요, 응찰 시 가장 적게 써낸 업체 선정 확률 높음

 사용자 관점



완벽한 기능뿐만 아니라  사용하기 쉽고 빨리 이해할 수 있는 아키텍처의 속성을 요구

 개발자 관점



플랫폼이 달라져도 새로운 플랫폼에 쉽게 적용할 수 있는 아키텍처의 속성에 관심



변경 요청 시 쉽게 변경할 수 있는 설계

34/89

4. 아키텍처 구축 절차(1)

 요구 사항 분석



소프트웨어 개발의 요구 사항 분석 단계와 같다

.



품질 속성과 같은 비기능적인 요구 사항에 더 많은 관심을 둠

     • 요구 사항 취득

, 식별, 명세, 분류, 검증

     • 기능적

/비기능적 요구 사항 분류 및 명세

35/89

4. 아키텍처 구축 절차(2)

 아키텍처 분석

 아키텍처 설계



관점 정의

: 이해 관계자 파악, 이해 관계자별 관점 정의



아키텍처 스타일 선택

: pipe-filter, mvc, layer 등의 스타일 혼용 적용 가



후보 아키텍처 도출

: 배경도 및 각 관점별 다이어그램 작성, 아키텍처 명세서 기술

 검증 및 승인



아키텍처 평가

: 아키텍처 요구 사항 만족도, 적합성, 품질 속성간 절충 관계 등 평가



아키텍처 상세화

(반복): 설계 방법 도출, 설계 패턴 고려



아키텍처 승인

: 이해 관계자들이 최종 승인

우선순위 결정

우선순위 결

품질 속성 식별

품질 속성 식

반영 방법 개발

반영 방법 개

36/89

5. 아키텍처의 4+1 관점(1)

37/89

5. 아키텍처의 4+1 관점(2)

38/89

5. 아키텍처의 4+1 관점(3)

 Usecase view



시스템이 사용자에게 제공하는 기능에 관심



다른 네 가지 관점에 사용되는 다이어그램의 근간

     • 정적 표현 

: 유스케이스 다이어그램

     • 동적 표현 

: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

 logical view(design view)



클래스나 컴포넌트의 종류와 이들의 관계에 초점

     • 정적 표현 

: 클래스 다이어그램, 객체 다이어그램

     • 동적 표현 

: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

39/89

5. 아키텍처의 4+1 관점(4)

 implementation view



소프트웨어 서브시스템의 모듈이 어떻게 구조화되어 있는가에 관심

     • 정적 표현 

: 컴포넌트 다이어그램

     • 동적 표현 

: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

 process view



실제 구동 환경을 살펴봄으로써 논리적 관점과 같이 시스템 내부의 구조에 초점



시스템의 동시성과 동기화에 관심

     • 동적 표현 

: 상태 다이어그램, 순차 다이어그램, 협동 다이어그램, 활동 다이어그램

     • 시스템 구성 표현 

: 컴포넌트 다이어그램, 배치 다이어그램

40/89

5. 아키텍처의 4+1 관점(5)

 deployment view



시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점



서브시스템들이 물리적인 환경에서 어떻게 연관되어 실행되는지를 나타냄

.



시스템의 분산 구조와 실행할 때 컴포넌트들의 배치 상태를 나타냄

.

• 정적 표현 

: 배치 다이어그램

• 동적 표현 

: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

41/89

6. 아키텍처 스타일(1)

 음식 스타일



한식

, 일식, 중식



음식 스타일에 따라 재료

, 조리 방법, 담을 그릇 등 결정

42/89

6. 아키텍처 스타일(2)

 아키텍처 스타일에 따라



구조

, 규칙, 요소, 기법 등이 결정



소프트웨어 특성

, 전체 구조, 개발 방법을 알 수 있다.

 좋은 소프트웨어 아키텍처 설계



소프트웨어에 적합한 아키텍처 스타일을 선택하고 적용하고 통합하는 것

 아키텍처 스타일을 사용한 설계의 장점

• 개발 기간 단축

, 고품질의 소프트웨어 생산

• 수월한 의사소통

• 용이한 유지보수

• 검증된 아키텍처

• 구축 전 시스템 특성에 대한 시뮬레이션 가능

• 기존 시스템에 대한 빠른 이해

43/89

6-1 아키텍처 스타일의 기능

      • 소프트웨어 시스템의 구조를 체계적으로 구성하기 위해 기본 스키마를 제시

      • 미리 정의된 서브시스템 제공

      • 각 아키텍처 패턴 간의 책임 명시

      • 패턴 간의 관계를 조직화하는 규칙

, 가이드라인 제시

      • 문제를 소프트웨어 모듈 단위로 분해하는 방법 제시

      • 분해한 소프트웨어 모듈 단위가 상호작용하는 방법 제시

44/89

7. 아키텍처 모델

45/89

7-1 데이터 중심형 모델(1)

 repository model



특징

: 주요 데이터가 repository에서 중앙 관리



구성

: repository와 여기에 접근하는 서브시스템

• repository : 공동으로 활용하는 데이터 보관

• 서브시스템: repository에 접근하여 정보를 저장, 검색, 변경하는 역할



대량의 데이터를 공유하는 은행 업무 시스템에 매우 유용한 모델

46/89

7-1 데이터 중심형 모델(2)

 장점



데이터가 한군데에 모여 있기 때문에 데이터를 모순되지 않고 일관성 있게 관리 가능



새로운 서브시스템의 추가 용이

 단점



repository의 병목 현상 발생 가능



서브시스템과 

repository 사이의 강한 결합

   ∴ repository 변경 시 서브시스템에 영향을 줌

47/89

7-2 client-server 모델

 Client-server 모델



네트워크를 이용하는 분산 시스템 형태



데이터와 처리 기능을 클라이언트와 서버에 분할하여 사용



분산 아키텍처에 유용

     • 서버

: 클라이언트(서브시스템)에 서비스 제공

     • 클라이언트

: 서버가 제공하는 서비스를 요청(호출)하는 서브시스템

48/89

7-3 계층 모델

 layering 모델



기능을 몇 개의 계층으로 나누어 배치



구성

: 하위 계층은 서버, 상위 계층은 클라이언트 역할

49/89

7-4 MVC 모델(1)

 Model/View/Controller 모델



중앙 데이터 구조



같은 모델의 서브시스템에 대하여 여러 뷰 서브시스템을 필요로 하는 시스템에 적합



세 개의 서브시스템으로 분리하는 이유

: 변경에 대한 영향을 덜 미치도록 하기 위해

           즉 

UI부분이 자주 변경되더라도 모델 서브시스템에는 영향을 주지 않기 위해

50/89

7-4 MVC 모델(2)

 Model 서브시스템



뷰

/제어 서브시스템과 독립되어 모든 데이터 상태와 로직을 처리



특정 입

·출력 방식에 영향을 받지 않고, 무언가의 호출에 응답만 함

 View 서브시스템



사용자와 직접 대화가 이루어지는 부분으로 데이터를 사용자에게 보여주는 역할

 Controller 서브시스템



뷰를 통한 사용자의 요청을 적절한 모델 쪽으로 넘겨주고

, 모델로부터 받은 응답을 다시 뷰를 

통해 사용자에게 돌려주는 역할

51/89

7-4 MVC 모델(3)

 장점



관심의 분리



데이터를 화면에 표현

(뷰)하는 디자인과 로직(모델)을 분리함으로써 느슨한 결합 가능



구조 변경 요청 시 수정 용이

 단점



기본 기능 설계로 인한 클래스 수의 증가로 복잡도 증가



속도가 중요한 프로젝트에 부적합

52/89

7-5 데이터 흐름 모델

 Pipe and filter 구조



Filter: data stream을 한 개 이상 입력 받아 처리(변환)한 후 data stream 하나를 출력



pipe: filter를 거쳐 생성된 data stream 하나를 다른 filter의 입력에 연결

Section 04 디자인 패턴

54/89

1. 디자인 패턴

 디자인 패턴



자주 사용하는 설계 형태를 정형화해서 이를 유형별로 설계 템플릿을 만들어둔 것 



많은 개발자들이 경험상 체득한 설계 지식을 검증하고 이를 추상화하여 일반화한 템플릿

55/89

2. 디자인 패턴 사용의 장/단점

 장점

• 개발자

(설계자) 간의 원활한 의사소통

• 소프트웨어 구조 파악 용이

• 재사용을 통한 개발 시간 단축

• 설계 변경 요청에 대한 유연한 대처

 단점

• 객체지향 설계

/구현 위주

• 초기 투자 비용 부담

56/89

3. Gof 디자인 패턴

초보자가 설계 잘할 수 있는 방법

전문가의 지식과 노하우 공유

SW설계 방법론과 지침 공유

사례 공유

구체적 문제 적용의 어려움

다른 유형에 적용의 어려움

GoF의 디자인 패턴

문제점

문제점

해결 방법

57/89

4. 디자인 패턴



여러 가지 문제에 대한 설계 사례를 

분석하여 서로 비슷한 문제를 해결하기 

위한 설계들을 분류하고

, 각 문제 

유형별로 가장 적합한 설계를 일반화해 

패턴으로 정립한 것을 의미



소프트웨어 설계에 대한 지식이나 

노하우가 문제 유형별로 잘 구체화되어 

있을 뿐 아니라

, 동일한 문제 유형에 

대해서는 그 해결 방법에 대한 지식이나 

노하우가 패턴 형태로 충분히 일반화된 

것 

58/89

4-1 factory method 패턴



Factory: 공장, 물건을 만드는 곳(물건-인스턴스)



상위 클래스에서 객체를 생성하는 인터페이스를 정의하고

, 하위 클래스에서 인스턴스를 

생성하도록 하는 방식



객체를 생성하는 시점은 알지만 어떤 객체를 생성해야 할지 알 수 없을 때

, 객체 생성을 하위 

클래스에 위임하여 해결

59/89

4-2 Singleton 패턴



Singleton: ‘단독 개체’, ‘독신자’라는 뜻 말고도 ‘정확히 하나의 요소만 갖는 집합’



특정 클래스의 객체가 오직 한 개만 존재하도록 보장

, 즉 클래스의 객체를 하나로 제한



동일한 자원이나 데이터를 처리하는 객체가 불필요하게 여러 개 만들어질 필요가 없는 경우에 

주로 사용

60/89

4-3 prototype 패턴



new Object( )보다 clone( )을 이용해 기존의 것을 복사하여 일부만 바꿔 인스턴스 생성



일반적인 

prototype(원형)을 만들어놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용



인스턴스를 복제하여 사용하는 구조



생성할 객체의 원형을 제공하는 프로토타입 인스턴스로부터 생성할 객체들의 타입 결정



객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용

61/89

4-4 Builder 패턴



복잡한 인스턴스를 조립하여 만드는 구조



복합 객체를 생성할 때 객체를 생성하는 방법

(과정)과 객체를 구현(표현)하는 방법을 분리



동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있다

.

62/89

4-5 abstract factory 패턴



abstract factory: ‘추상적인 공장’, 



[그림 5-33]과 같이 여러 개의 concrete Product를 추상화시킨 것



구체적인 구현은 

concreteProduct 클래스에서 이루어짐



사용자에게 

API를 제공하고, 인터페이스만 사용해서 부품을 조립하여 만든다. 

  즉 추상적인 부품을 조합해서 추상적인 제품을 만든다

.

63/89

4-6 Composite 패턴



Composite: ‘합성의’, ‘합성물’, ‘혼합 양식’



composite object: 부분-전체의 상속 구조로 표현되는 조립 객체



사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한 것



재귀적 구조

: 디렉토리 안에 파일 또는 다른 디렉토리(서브 디렉토리)가 존재할 수 있는 것



그릇

(디렉토리)과 내용물(파일)을 동일시해서 재귀적인 구조를 만들기 위한 설계 패턴

64/89

4-7 adapter 패턴(1)

 adapter



‘접속 소켓’

, ‘확장 카드’, ‘(물건을 다른 것에) 맞추어 붙이다’, ‘맞추다’

65/89

4-7 adapter 패턴(2)

 adapter 패턴



기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할



호환성이 없는 기존 클래스의 인터페이스를 변환해 재사용할 수 있도록 해준다

.

• 클래스 

adapter 패턴 : 상속을 이용한 어댑터 패턴

• 인스턴스 

adapter 패턴 : 위임을 이용한 어댑터 패턴

66/89

4-8 bridge 패턴



bridge: ‘무엇인가를 연결한다’



두 장소를 연결하는 역할



기능의 클래스 계층과 구현의 클래스 계층을 연결하고

, 구현부에서 추상계층을 분리하여 각자 

독립적으로 변형할 수 있게 해준다

.



구현과 인터페이스

(추상화된 부분)를 분리할 수 있고, 추상화된 부분과 실제 구현 부분

   을 독립적으로 확장할 수 있다

.

67/89

4-9 decorator 패턴



Decoration: ‘장식(포장)’



기존에 구현되어 있는 클래스

(둥근 모양의 빵)에 그때그때 필요한 기능(초콜릿, 치즈,

생크림

)을 추가(장식, 포장)해나가는 설계 패턴



기능확장이 필요할 때 상속의 대안으로 사용

68/89

4-10 facade 패턴



Façade: ‘건물의 앞쪽 정면(전면)’



몇 개의 클라이언트 클래스와 서브시스템의 클라이언트 사이에 

facade라는 객체를 

세워놓음으로써 복잡한 관계를 정리

(구조화)한 것



모든 관계가 전면에 세워진 

facade 객체를 통해서만 이루어질 수 있게 단순한 인터페이스를 

제공

(단순한 창구 역할)하는 것

69/89

4-11 Flyweight 패턴



Flyweight: ‘(권투·레슬링 등의) 플라이급 선수(보통 체중 48~51kg 사이)’, 즉 가벼운 것



메모리를 가볍게 해준다고 짐작할 수 있다

.



메모리 사용량을 줄이기 위한 방법으로

, 인스턴스를 필요한 대로 다 만들어 쓰지 말고, 동일한 

것은 가능하면 공유해서 객체 생성을 줄이자는 것

70/89

4-12 Proxy 패턴



Proxy: ‘대리인’, 즉 뭔가를 대신해서 처리하는 것



그림과 텍스트가 섞여있는 경우 텍스트가 먼저 나오고 나중에 그림이 나올 수 있도록 하기 위해 

텍스트 처리용 프로세스

, 그림 처리용 프로세스를 별도로 두고 운영하는 것 같은 설계

71/89

4-13 iterator 패턴(1)



Iterate: ‘반복하다’, iterator: ‘반복자’



반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근할 수 있도록 아래 그림 처럼 

it-

erator 객체 속에 넣은 다음, iterator 객체의 메서드를 이용해 자료구조를 활용할 수 있도록 

해준다

.



데이터들의 집합체를 모두 동일한 인터페이스를 사용하여 조작함으로써 데이터들의 집합체를 

쉽게 사용할 수 있게 해준다

.

72/89

4-13 iterator 패턴(2)

73/89

4-14 Observer 패턴(1)



Observer:  ‘관찰하는 사람’, ‘관찰자’



위 그림의 예처럼 어떤 클래스에 변화가 일어났을 때

, 이를 감지하여 다른 클래스에 통보해주는 

것

74/89

4-14 Observer 패턴(2)

75/89

4-15 strategy 패턴(1)



Strategy: ‘전략’, ‘전술’ 



소프트웨어 개발에서 전략이나 전술은 알고리즘으로 구현



위 그림처럼 알고리즘 군을 정의하고

(strategySort 추상클래스) 같은 알고리즘(버블 정렬, 퀵 

정렬

, 선택 정렬 등)을 각각 하나의 클래스로 캡슐화한(quickSort 클래스, selectSort 클래스, 

bubbleSort 클래스) 다음, 필요할 때 서로 교환해서사용할 수 있게 해준다.

76/89

4-15 strategy 패턴(2)

 Strategy 패턴 



클라이언트와 무관하게 독립적으로 알고리즘 변경 가능

(quickSort →bubbleSort), 

클라이언트는 독립적으로 원하는 알고리즘 사용 가능



클라이언트에게 알고리즘이 사용하는 데이터나 그 구조를 숨겨주는 역할



알고리즘을 사용하는 곳과

, 알고리즘을 제공하는 곳을 분리시킨 구조로알고리즘을 동적으로 

교체 가능

77/89

4-16 template method 패턴



Template: 하나의 ‘틀’



이런 틀 기능을 구현할 때 

template method 패턴을 이용



상위 클래스에서는 추상적으로 표현하고 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 

패턴

78/89

4-17 Visitor 패턴(1)



Visitor: ‘방문자



위 그림처럼 각 클래스의 데이터 구조로부터 처리 기능을 분리하여 별도의 

visitor 클래스로 

만들어놓고 해당 클래스의 메서드

(visitElement A, visitElement B)가 각 클래스를 

돌아다니며 특정 작업을 수행하도록 하는 것

79/89

4-17 Visitor 패턴(2)

 Visitor 패턴



객체의 구조와 기능을 분리



객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 많이 사용



장점

: 클래스의 데이터 구조 변경 없이 기존 작업(기능) 외에 다른 작업을 추가하기가 수월

80/89

4-18 chine of responsibility 패턴(1)

 chine of responsibility



책임들이 연결되어 있어 내가 책임을 못 질 것 같으면 다음 책임자에게 자동으로 넘어가는 구조



소프트웨어 개발에서도 이렇게 자동으로 연결되는 구조로 프로그램을 만들면 매우 유용한데 이 

개념을 적용할 수 있는 것이 바로 

chine of responsibility 패턴

81/89

4-18 chine of responsibility 패턴(2)

 chine of responsibility 패턴

82/89

4-19 command 패턴(1)



Command: ‘명령어’

  (예) 문서편집기의 복사(copy), 붙여넣기(paste), 잘라내기(cut) 등



위의 명령어를 각각 구현하는 것보다는 위 그림처럼 하나의 추상 클래스에 

execute( ) 메서드를 

하나 만들고 각 명령이 들어오면 그에 맞는 서브 클래스

(copy_command)가 선택되어 

실행하는 것이 효율적

83/89

4-19 command 패턴(2)

 Command 패턴



단순히 명령어를 추상 클래스와 구체 클래스로 분리하여 단순화한 것으로 끝나지 않고

, 명령어에 

따른 취소

(undo) 기능까지 포함

• 이유: 사용자 입장에서는 해당 명령어를 실행했다가 취소(undo)하기도 하기 때문



이렇게 프로그램의 명령어를 구현할 때 

command 패턴을 활용

84/89

4-20 mediator 패턴(1)



Mediator: ‘중재자’, ‘조정자’, ‘중개인’



부동산 중개사

, 비행기의 이착륙을 통제하는 관제탑, 중고물건을 사고파는 사이트처럼 중간에서 

연결하고 통제하는 역할  

85/89

4-20 mediator 패턴(2)

86/89

4-21 state 패턴



State: ‘상태’



동일한 동작을 객체 상태에 따라 다르게 처리해야 할 때 사용



아래 그림처럼 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식으로 상태에 따라 

다르게 처리

(upState, stopState, downState)할 수 있도록 한 것



변경 시

(신규 상태 추가) 원시 코드의 수정을 최소화할 수 있고, 유지보수를 쉽게 할 수 있다.

87/89

4-22 memento 패턴



Memento: ‘(사람, 장소를 기억하기 위한) 기념품’



undo 기능을 개발할 때 유용



클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용

88/89

4-23 interpreter 패턴



Interpreter: ‘통역자’



단어의 의미처럼 무언가를 번역하는 데 사용



간단한 언어의 문법을 정의하고 해석하는 데 사용



문법 규칙을 클래스화한 구조를 갖는

SQL 언어나 통신 프로토콜 같은 것을 개발할 때 사용

Thank You