Chatpter 05 상위 설계 01 설계의 이해 02 설계의 원리 03 소프트웨어 아키텍처 04 디자인 패턴 요약 연습문제

소프트웨어 설계 원리를 이해한다. 소프트웨어 아키텍처를 살펴본다. 소프트웨어 아키텍처 스타일을 알아본다. 소프트웨어 디자인 패턴을 살펴본다.

Section 01 설계의 이해

1. 설계의 이해

1-1 설계의 예: 옷본

1-2 건축 설계 과정

2. 소프트웨어 설계 분석 단계 설계 단계 설계 사용자의 요구 사항을 토대로 요구 분석 명세서 작성 개념적이고 추상적, what(무엇) 관점 설계 단계 분석 단계에서 파악한 비기능적 요구 사항과 제약 사항 고려 운영체제·미들웨어·프레임워크 등의 플랫폼 결정, how(어떻게) 관점 설계 요구 분석 명세서를 기반으로 어떻게 구축할 것인가를 결정하는 것 설계자: 다양한 제약 조건을 만족시킬 수 있는 최적의 설계안을 만드는 것이 중요 설계를 평가할 수 있는 기준도 정량적으로 명시

3. 좋은 설계의 조건 • 요구 분석 명세서의 내용을 설계서에 모두 포함해야 한다. • 유지보수가 용이하도록 추적이 가능해야 한다. • 변화에 쉽게 적응할 수 있어야 한다. • 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 한다. • 설계서는 읽기 쉽고, 이해하기 쉽게 작성해야 한다.

4. 설계의 종류(1)

4. 설계의 종류(2) 상위 설계(예비 설계preliminary design) 하위 설계 • 아키텍처(구조) 설계 : 시스템의 전체적인 구조 • 데이터 설계 : 시스템에 필요한 정보를 자료구조와 데이터베이스 설계에 반영 • 시스템 분할 : 전체 시스템을 여러 개의 서브시스템으로 나눈다. • 인터페이스 정의 : 시스템의 구조와 서브시스템들 사이의 인터페이스가 명확히 정의 • UI 설계 : 사용자가 익숙하고 편리하게 사용할 수 있도록 사용자 인터페이스설계 하위 설계 • 각 모듈의 실제적인 내부를 알고리즘(pseudo-code) 형태로 표현 • 인터페이스에 대한 설명, 자료구조, 변수 등에 대한 상세한 정보를 작성

Section 02 설계의 원리

1. 설계의 원리

2. 분할과 정복의 원리 분할과 정복 큰 문제를 소 단위로 나누고 소 단위의 작업을 하나씩 처리하여 전체 일을 끝내는 방법 (예) 대학의 종합정보시스템: 학사 관리, 회계 관리, 인사 관리 등으로 나눔 학사 관리: 수강 관리, 수업 관리, 성적 관리 등으로 나눔 분할 형태 • 분산 시스템은 클라이언트와 서버로 분할 • 시스템은 여러 서브시스템으로 분할 • 서브시스템은 하나 이상의 패키지로 분할 • 패키지는 여러 클래스로 분할 • 클래스는 여러 메서드로 분할

3. 추상화의 원리 추상화abstraction 주어진 문제(건물 도면)에서 현재의 관심사에 초점을 맞추기 위해, 특정한 목적과 관련된 필수 정보만 추출하여 강조하고(전기 배선도, 상하수도 배관도 등) 관련이 없는 세부 사항을 생략함으로써 본질적인 문제에 집중할 수 있도록 하는 작업

3-1 도형의 추상화

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

3-3 추상화의 종류(1) 과정 추상화procedure abstraction

3-3 추상화의 종류(2) Class의 특징 데이터 추상화data abstraction 사용자에게 클래스가 제공할 수 있는 사용법만 알려주고, 불필요한 데이터와 연산을 감춤 사용자는 클래스에서 제공하는 연산 기능만 알고 그 연산을 사용하여 데이터 값을 변경 데이터 추상화data abstraction 대표적인 예: C++ 언어의 클래스

3-3 추상화의 종류(3) 제어 추상화control abstraction

4. 단계적 분해 단계적 분해 하향식 설계에서 사용 기능을 점점 작은 단위로 나누어 점차적으로 구체화하는 방법

5. 모듈화 모듈 모듈의 특징 ‘규모가 큰 것을 여러 개로 나눈 조각’ ‘소프트웨어 구조를 이루는 기본적인 단위’ ‘하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합’ 라이브러리 함수, 그래픽 함수 라이브러리 함수, 그래픽 함수, 추상화된 자료, subroutine, procedure, object, method → 독립 프로그램도 하나의 모듈로 가능, 함수들도 하나의 모듈로 가능 모듈의 특징 다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위이다. 유일한 이름을 가져야 한다. 독립적으로 컴파일이 가능하다. 모듈에서 또 다른 모듈을 호출할 수 있다. 다른 프로그램에서도 모듈을 호출할 수 있다.

Section 03 소프트웨어 아키텍처

1. 소프트웨어 아키텍처

2. 아키텍처의 특징과 기능(1) 아키텍처의 정의 소프트웨어 아키텍처 구성 요소 구성 요소들 사이의 관계 구성 요소들이 외부에 드러내는 속성 구성 요소들과 주변 환경 사이의 관계 구성 요소들이 제공하는 인터페이스 구성 요소들의 협력 및 조립 방법 소프트웨어 아키텍처 개발할 소프트웨어 대한 전체적인 구조를 다룬다. 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룬다. 구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지를 정의해야 한다. 세부 내용보다는 중요한 부분만을 다룬다. 시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 한다.

2. 아키텍처의 특징과 기능(2) 아키텍처의 설계 시 고려 사항 아키텍처의 설계 시 기술 방법 의사소통 도구로 활용할 수 있어야 한다. 구현에 대한 제약 사항을 정의해야 한다. 품질 속성을 결정해야 한다. 재사용할 수 있게 설계해야 한다. 아키텍처의 설계 시 기술 방법 이해하기 쉽게 작성 명확하게 기술 표준화된 형식 사용 문서 버전 명시

3. 아키텍처의 품질 속성 품질 요구 사항 소프트웨어 아키텍처 시스템이 제공해야 하는 품질 속성의 수준 가능하면 정확한 수치로 제시 소프트웨어 아키텍처 이해 관계자들의 품질 요구 사항을 반영하여 품질 속성을 결정

3-1 시스템 품질 속성(1) 가용성(availability) 변경 용이성(modifiability) 시스템이 운용될 수 있는 확률로, 시스템이 장애 발생 없이 서비스를 제공할 수 있는 능력 가용성을 높이려면: 하드웨어 이중화처럼 여분의 구성 요소를 포함하도록 설계 변경 용이성(modifiability) 변경 요구 사항을 받았을 때 쉽게 변경할 수 있는 능력 빈번하게 변경할 가능성이 높은 소프트웨어는 변경 용이성을 고려하여 아키텍처를 결정 성능(performance) 사용자 요청과 같은 이벤트가 발생했을 때, 빠르고 적절하게 반응할 수 있는 능력 공유 자원을 어떻게 사용하는지, 어떤 알고리즘을 사용해 구현하는지 등의 요소와 밀접

3-1 시스템 품질 속성(2) 보안성(security) 사용성(usability) 테스트 용이성(testability) 허용되지 않은 접근에 대응할 수 있는 능력 사용성(usability) 소프트웨어를 사용할 때 혼란스러워하거나 사용하는 순간에 고민하지 않게 하는 편의성 테스트 용이성(testability) 사용자가 요구하는 기능을 만족스럽게 잘 수행하고 있는지를 얼마나 쉽고 철저하게 테스트할 수 있는지를 나타낸다.

3-2 비즈니스 품질 속성(1) 시장 적시성time to market 비용과 이익cost and benefit 정해진 날짜에 소프트웨어를 출시해 경쟁력을 높일 수 있는 정도 비용과 이익cost and benefit 비용을 더 들여 사용하고 효과를 볼 것인지, 아니면 비용을 절약하는 데 중심을 둘 것인지를 말한다. 아키텍처를 설계 시: 비용을 더 많이 들여 유연한 설계를 할 것인지, 비용을 절감하는데 초점을 맞출 것인지 판단해야 함 예상 시스템 수명predicted lifetime of the system 수명이 중요한 경우라면 변경 용이성, 확장성, 이식성을 더 중요하게 고려

3-2 비즈니스 품질 속성(2) 목표 시장targeted market 패키지 소프트웨어: 기능성 및 다양한 플랫폼에서도 잘 작동되어야 하므로 이식성을 충분히 고려한 설계 필요 신규 발매 일정 또는 공개 일정rollout schedule 현재 버전에서는 기본 기능만 제공하고, 추후에 배포할 차기 버전에서 기능을 추가하여 완성도를 높일 예정이라면 유연성flexibility과 확장성을 고려한 설계 필요 기존 시스템과의 통합integration with legacy system 아키텍처 설계 시 기존 시스템과의 통합 방법을 충분히 고려한 설계 필요

3-3 아키텍처 품질 속성 개념적 무결성conceptual integrity 개념적 무결성은 일관성이라고도 함 전체 시스템과 시스템 구성 요소가 일관되도록 아키텍처를 결정 정확성과 완전성correctness and completeness 사용자가 요구하는 기능을 충족시키는 정도로, 요구 분석 명세서와 일치하는 정도 개발 용이성(구축 가능성, buildability) 전체 시스템을 적절한 모듈로 분할한 후 개발 팀에 알맞게 분배하여 개발함으로써 정해진 기간 내에 완성하고, 개발 과정 중에도 쉽게 변경할 수 있는 능력

3-4 이해 관계자별 품질 속성 발주자 관점 사용자 관점 개발자 관점 제품 가격(또는 개발비)이 중요, 응찰 시 가장 적게 써낸 업체 선정 확률 높음 사용자 관점 완벽한 기능뿐만 아니라 사용하기 쉽고 빨리 이해할 수 있는 아키텍처의 속성을 요구 개발자 관점 플랫폼이 달라져도 새로운 플랫폼에 쉽게 적용할 수 있는 아키텍처의 속성에 관심 변경 요청 시 쉽게 변경할 수 있는 설계

4. 아키텍처 구축 절차(1) 요구 사항 분석 소프트웨어 개발의 요구 사항 분석 단계와 같다. 품질 속성과 같은 비기능적인 요구 사항에 더 많은 관심을 둠 • 요구 사항 취득, 식별, 명세, 분류, 검증 • 기능적/비기능적 요구 사항 분류 및 명세

4. 아키텍처 구축 절차(2) 아키텍처 분석 아키텍처 설계 검증 및 승인 우선순위 결정 품질 속성 식별 반영 방법 개발 관점 정의: 이해 관계자 파악, 이해 관계자별 관점 정의 아키텍처 스타일 선택: pipe-filter, mvc, layer 등의 스타일 혼용 적용 가 후보 아키텍처 도출: 배경도 및 각 관점별 다이어그램 작성, 아키텍처 명세서 기술 검증 및 승인 아키텍처 평가: 아키텍처 요구 사항 만족도, 적합성, 품질 속성간 절충 관계 등 평가 아키텍처 상세화(반복): 설계 방법 도출, 설계 패턴 고려 아키텍처 승인: 이해 관계자들이 최종 승인 우선순위 결정 품질 속성 식별 반영 방법 개발

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

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

5. 아키텍처의 4+1 관점(3) Usecase view logical view(design view) 시스템이 사용자에게 제공하는 기능에 관심 다른 네 가지 관점에 사용되는 다이어그램의 근간 • 정적 표현 : 유스케이스 다이어그램 • 동적 표현 : 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램 logical view(design view) 클래스나 컴포넌트의 종류와 이들의 관계에 초점 • 정적 표현 : 클래스 다이어그램, 객체 다이어그램

5. 아키텍처의 4+1 관점(4) implementation view process view 소프트웨어 서브시스템의 모듈이 어떻게 구조화되어 있는가에 관심 • 정적 표현 : 컴포넌트 다이어그램 • 동적 표현 : 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램 process view 실제 구동 환경을 살펴봄으로써 논리적 관점과 같이 시스템 내부의 구조에 초점 시스템의 동시성과 동기화에 관심 • 동적 표현 : 상태 다이어그램, 순차 다이어그램, 협동 다이어그램, 활동 다이어그램 • 시스템 구성 표현 : 컴포넌트 다이어그램, 배치 다이어그램

5. 아키텍처의 4+1 관점(5) deployment view 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점 서브시스템들이 물리적인 환경에서 어떻게 연관되어 실행되는지를 나타냄. 시스템의 분산 구조와 실행할 때 컴포넌트들의 배치 상태를 나타냄. • 정적 표현 : 배치 다이어그램 • 동적 표현 : 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

6. 아키텍처 스타일(1) 음식 스타일 한식, 일식, 중식 음식 스타일에 따라 재료, 조리 방법, 담을 그릇 등 결정

6. 아키텍처 스타일(2) 아키텍처 스타일에 따라 좋은 소프트웨어 아키텍처 설계 아키텍처 스타일을 사용한 설계의 장점 구조, 규칙, 요소, 기법 등이 결정 소프트웨어 특성, 전체 구조, 개발 방법을 알 수 있다. 좋은 소프트웨어 아키텍처 설계 소프트웨어에 적합한 아키텍처 스타일을 선택하고 적용하고 통합하는 것 아키텍처 스타일을 사용한 설계의 장점 • 개발 기간 단축, 고품질의 소프트웨어 생산 • 수월한 의사소통 • 용이한 유지보수 • 검증된 아키텍처 • 구축 전 시스템 특성에 대한 시뮬레이션 가능 • 기존 시스템에 대한 빠른 이해

6-1 아키텍처 스타일의 기능 • 소프트웨어 시스템의 구조를 체계적으로 구성하기 위해 기본 스키마를 제시 • 미리 정의된 서브시스템 제공 • 각 아키텍처 패턴 간의 책임 명시 • 패턴 간의 관계를 조직화하는 규칙, 가이드라인 제시 • 문제를 소프트웨어 모듈 단위로 분해하는 방법 제시 • 분해한 소프트웨어 모듈 단위가 상호작용하는 방법 제시

7. 아키텍처 모델

7-1 데이터 중심형 모델(1) repository model 특징: 주요 데이터가 repository에서 중앙 관리 대량의 데이터를 공유하는 은행 업무 시스템에 매우 유용한 모델

7-1 데이터 중심형 모델(2) 장점 단점 데이터가 한군데에 모여 있기 때문에 데이터를 모순되지 않고 일관성 있게 관리 가능 새로운 서브시스템의 추가 용이 단점 repository의 병목 현상 발생 가능 서브시스템과 repository 사이의 강한 결합 ∴ repository 변경 시 서브시스템에 영향을 줌

7-2 client-server 모델 Client-server 모델 네트워크를 이용하는 분산 시스템 형태 데이터와 처리 기능을 클라이언트와 서버에 분할하여 사용 분산 아키텍처에 유용 • 서버: 클라이언트(서브시스템)에 서비스 제공 • 클라이언트: 서버가 제공하는 서비스를 요청(호출)하는 서브시스템

7-3 계층 모델 layering 모델 기능을 몇 개의 계층으로 나누어 배치 구성: 하위 계층은 서버, 상위 계층은 클라이언트 역할

7-4 MVC 모델(1) Model/View/Controller 모델 중앙 데이터 구조 같은 모델의 서브시스템에 대하여 여러 뷰 서브시스템을 필요로 하는 시스템에 적합 세 개의 서브시스템으로 분리하는 이유: 변경에 대한 영향을 덜 미치도록 하기 위해 즉 UI부분이 자주 변경되더라도 모델 서브시스템에는 영향을 주지 않기 위해

7-4 MVC 모델(2) Model 서브시스템 View 서브시스템 Controller 서브시스템 뷰/제어 서브시스템과 독립되어 모든 데이터 상태와 로직을 처리 특정 입·출력 방식에 영향을 받지 않고, 무언가의 호출에 응답만 함 View 서브시스템 사용자와 직접 대화가 이루어지는 부분으로 데이터를 사용자에게 보여주는 역할 Controller 서브시스템 뷰를 통한 사용자의 요청을 적절한 모델 쪽으로 넘겨주고, 모델로부터 받은 응답을 다시 뷰를 통해 사용자에게 돌려주는 역할

7-4 MVC 모델(3) 장점 관심의 분리 데이터를 화면에 표현(뷰)하는 디자인과 로직(모델)을 분리함으로써 느슨한 결합 가능 구조 변경 요청 시 수정 용이 단점 기본 기능 설계로 인한 클래스 수의 증가로 복잡도 증가 속도가 중요한 프로젝트에 부적합

7-5 데이터 흐름 모델 Pipe and filter 구조 Filter: data stream을 한 개 이상 입력 받아 처리(변환)한 후 data stream 하나를 출력 pipe: filter를 거쳐 생성된 data stream 하나를 다른 filter의 입력에 연결

Section 04 디자인 패턴

1. 디자인 패턴 디자인 패턴 자주 사용하는 설계 형태를 정형화해서 이를 유형별로 설계 템플릿을 만들어둔 것 많은 개발자들이 경험상 체득한 설계 지식을 검증하고 이를 추상화하여 일반화한 템플릿

2. 디자인 패턴 사용의 장/단점 장점 단점 • 개발자(설계자) 간의 원활한 의사소통 • 소프트웨어 구조 파악 용이 • 재사용을 통한 개발 시간 단축 • 설계 변경 요청에 대한 유연한 대처 단점 • 객체지향 설계/구현 위주 • 초기 투자 비용 부담

3. Gof 디자인 패턴 초보자가 설계 잘할 수 있는 방법 전문가의 지식과 노하우 공유 SW설계 방법론과 지침 공유 사례 공유 문제점 문제점 구체적 문제 적용의 어려움 다른 유형에 적용의 어려움 해결 방법 GoF의 디자인 패턴

4. 디자인 패턴 여러 가지 문제에 대한 설계 사례를 분석하여 서로 비슷한 문제를 해결하기 위한 설계들을 분류하고, 각 문제 유형별로 가장 적합한 설계를 일반화해 패턴으로 정립한 것을 의미 소프트웨어 설계에 대한 지식이나 노하우가 문제 유형별로 잘 구체화되어 있을 뿐 아니라, 동일한 문제 유형에 대해서는 그 해결 방법에 대한 지식이나 노하우가 패턴 형태로 충분히 일반화된 것

4-1 factory method 패턴 Factory: 공장, 물건을 만드는 곳(물건-인스턴스) 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식 객체를 생성하는 시점은 알지만 어떤 객체를 생성해야 할지 알 수 없을 때, 객체 생성을 하위 클래스에 위임하여 해결

4-2 Singleton 패턴 Singleton: ‘단독 개체’, ‘독신자’라는 뜻 말고도 ‘정확히 하나의 요소만 갖는 집합’ 특정 클래스의 객체가 오직 한 개만 존재하도록 보장, 즉 클래스의 객체를 하나로 제한 동일한 자원이나 데이터를 처리하는 객체가 불필요하게 여러 개 만들어질 필요가 없는 경우에 주로 사용

4-3 prototype 패턴 new Object( )보다 clone( )을 이용해 기존의 것을 복사하여 일부만 바꿔 인스턴스 생성 일반적인 prototype(원형)을 만들어놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용 인스턴스를 복제하여 사용하는 구조 생성할 객체의 원형을 제공하는 프로토타입 인스턴스로부터 생성할 객체들의 타입 결정 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용

4-4 Builder 패턴 복잡한 인스턴스를 조립하여 만드는 구조 복합 객체를 생성할 때 객체를 생성하는 방법(과정)과 객체를 구현(표현)하는 방법을 분리 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있다.

4-5 abstract factory 패턴 abstract factory: ‘추상적인 공장’, [그림 5-33]과 같이 여러 개의 concrete Product를 추상화시킨 것 구체적인 구현은 concreteProduct 클래스에서 이루어짐 사용자에게 API를 제공하고, 인터페이스만 사용해서 부품을 조립하여 만든다. 즉 추상적인 부품을 조합해서 추상적인 제품을 만든다.

4-6 Composite 패턴 Composite: ‘합성의’, ‘합성물’, ‘혼합 양식’ composite object: 부분-전체의 상속 구조로 표현되는 조립 객체 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한 것 재귀적 구조: 디렉토리 안에 파일 또는 다른 디렉토리(서브 디렉토리)가 존재할 수 있는 것 그릇(디렉토리)과 내용물(파일)을 동일시해서 재귀적인 구조를 만들기 위한 설계 패턴

4-7 adapter 패턴(1) adapter ‘접속 소켓’, ‘확장 카드’, ‘(물건을 다른 것에) 맞추어 붙이다’, ‘맞추다’

4-7 adapter 패턴(2) adapter 패턴 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할 호환성이 없는 기존 클래스의 인터페이스를 변환해 재사용할 수 있도록 해준다. • 클래스 adapter 패턴 : 상속을 이용한 어댑터 패턴 • 인스턴스 adapter 패턴 : 위임을 이용한 어댑터 패턴

4-8 bridge 패턴 bridge: ‘무엇인가를 연결한다’ 두 장소를 연결하는 역할 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상계층을 분리하여 각자 독립적으로 변형할 수 있게 해준다. 구현과 인터페이스(추상화된 부분)를 분리할 수 있고, 추상화된 부분과 실제 구현 부분 을 독립적으로 확장할 수 있다.

4-9 decorator 패턴 Decoration: ‘장식(포장)’ 기존에 구현되어 있는 클래스(둥근 모양의 빵)에 그때그때 필요한 기능(초콜릿, 치즈, 생크림)을 추가(장식, 포장)해나가는 설계 패턴 기능확장이 필요할 때 상속의 대안으로 사용

4-10 facade 패턴 Façade: ‘건물의 앞쪽 정면(전면)’

4-11 Flyweight 패턴 Flyweight: ‘(권투·레슬링 등의) 플라이급 선수(보통 체중 48~51kg 사이)’, 즉 가벼운 것 메모리를 가볍게 해준다고 짐작할 수 있다. 메모리 사용량을 줄이기 위한 방법으로, 인스턴스를 필요한 대로 다 만들어 쓰지 말고, 동일한 것은 가능하면 공유해서 객체 생성을 줄이자는 것

4-12 Proxy 패턴 Proxy: ‘대리인’, 즉 뭔가를 대신해서 처리하는 것 그림과 텍스트가 섞여있는 경우 텍스트가 먼저 나오고 나중에 그림이 나올 수 있도록 하기 위해 텍스트 처리용 프로세스, 그림 처리용 프로세스를 별도로 두고 운영하는 것 같은 설계

4-13 iterator 패턴(1) Iterate: ‘반복하다’, iterator: ‘반복자’ 반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근할 수 있도록 아래 그림 처럼 iterator 객체 속에 넣은 다음, iterator 객체의 메서드를 이용해 자료구조를 활용할 수 있도록 해준다. 데이터들의 집합체를 모두 동일한 인터페이스를 사용하여 조작함으로써 데이터들의 집합체를 쉽게 사용할 수 있게 해준다.

4-13 iterator 패턴(2)

4-14 Observer 패턴(1) Observer: ‘관찰하는 사람’, ‘관찰자’ 위 그림의 예처럼 어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보해주는 것

4-14 Observer 패턴(2)

4-15 strategy 패턴(1) Strategy: ‘전략’, ‘전술’ 소프트웨어 개발에서 전략이나 전술은 알고리즘으로 구현 위 그림처럼 알고리즘 군을 정의하고(strategySort 추상클래스) 같은 알고리즘(버블 정렬, 퀵 정렬, 선택 정렬 등)을 각각 하나의 클래스로 캡슐화한(quickSort 클래스, selectSort 클래스, bubbleSort 클래스) 다음, 필요할 때 서로 교환해서사용할 수 있게 해준다.

4-15 strategy 패턴(2) Strategy 패턴 클라이언트와 무관하게 독립적으로 알고리즘 변경 가능(quickSort →bubbleSort), 클라이언트는 독립적으로 원하는 알고리즘 사용 가능 클라이언트에게 알고리즘이 사용하는 데이터나 그 구조를 숨겨주는 역할 알고리즘을 사용하는 곳과, 알고리즘을 제공하는 곳을 분리시킨 구조로알고리즘을 동적으로 교체 가능

4-16 template method 패턴 Template: 하나의 ‘틀’ 상위 클래스에서는 추상적으로 표현하고 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴

4-17 Visitor 패턴(1) Visitor: ‘방문자 위 그림처럼 각 클래스의 데이터 구조로부터 처리 기능을 분리하여 별도의 visitor 클래스로 만들어놓고 해당 클래스의 메서드(visitElement A, visitElement B)가 각 클래스를 돌아다니며 특정 작업을 수행하도록 하는 것

4-17 Visitor 패턴(2) Visitor 패턴 객체의 구조와 기능을 분리 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 많이 사용 장점: 클래스의 데이터 구조 변경 없이 기존 작업(기능) 외에 다른 작업을 추가하기가 수월

4-18 chine of responsibility 패턴(1) 책임들이 연결되어 있어 내가 책임을 못 질 것 같으면 다음 책임자에게 자동으로 넘어가는 구조 소프트웨어 개발에서도 이렇게 자동으로 연결되는 구조로 프로그램을 만들면 매우 유용한데 이 개념을 적용할 수 있는 것이 바로 chine of responsibility 패턴

4-18 chine of responsibility 패턴(2)

4-19 command 패턴(1) Command: ‘명령어’ (예) 문서편집기의 복사(copy), 붙여넣기(paste), 잘라내기(cut) 등 위의 명령어를 각각 구현하는 것보다는 위 그림처럼 하나의 추상 클래스에 execute( ) 메서드를 하나 만들고 각 명령이 들어오면 그에 맞는 서브 클래스(copy_command)가 선택되어 실행하는 것이 효율적

4-19 command 패턴(2) Command 패턴 단순히 명령어를 추상 클래스와 구체 클래스로 분리하여 단순화한 것으로 끝나지 않고, 명령어에 따른 취소(undo) 기능까지 포함 이유: 사용자 입장에서는 해당 명령어를 실행했다가 취소(undo)하기도 하기 때문 이렇게 프로그램의 명령어를 구현할 때 command 패턴을 활용

4-20 mediator 패턴(1) Mediator: ‘중재자’, ‘조정자’, ‘중개인’ 부동산 중개사, 비행기의 이착륙을 통제하는 관제탑, 중고물건을 사고파는 사이트처럼 중간에서 연결하고 통제하는 역할

4-20 mediator 패턴(2)

4-21 state 패턴 State: ‘상태’ 동일한 동작을 객체 상태에 따라 다르게 처리해야 할 때 사용 아래 그림처럼 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리(upState, stopState, downState)할 수 있도록 한 것 변경 시(신규 상태 추가) 원시 코드의 수정을 최소화할 수 있고, 유지보수를 쉽게 할 수 있다.

4-22 memento 패턴 Memento: ‘(사람, 장소를 기억하기 위한) 기념품’ undo 기능을 개발할 때 유용 클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용

4-23 interpreter 패턴 Interpreter: ‘통역자’ 간단한 언어의 문법을 정의하고 해석하는 데 사용 단어의 의미처럼 무언가를 번역하는 데 사용 간단한 언어의 문법을 정의하고 해석하는 데 사용 문법 규칙을 클래스화한 구조를 갖는SQL 언어나 통신 프로토콜 같은 것을 개발할 때 사용