3. 애플리케이션 설계

kyunge_ev 2023. 11. 27. 22:07

✅ 공통 모듈 설계

1. 설계 모델링

(1) 소프트웨어 설계 개념

요구사항 분석 단계에서 나온 사용자가 필요로 하는 필수 기능 구현 방법을 명시하는 것
물리적 구현이 가능하도록 절차나 시스템을 구체적으로 정의하는 데 있어 여러 기술과 원리를 응용하는 작업

📌 설계의 기본 원리

구분내용추상화(Abstraction)구조화(Structuralization)모듈화(Modularity)

구분	내용
추상화 (Abstraction)	- 복잡한 문제를 이해하기 위해 필요 없는 세부 사항을 배제하는 것을 의미 - 복잡한 구조(문제)를 해결하기 위해 설계 대상의 상세 내용은 배제하고, 유사점을 요약해서 표현하는 기법 - 종류 : 과정 추상화, 자료 추상화, 제어 추상화
구조화 (Structuralization)	문제 영역들을 각각의 기능 모듈 단위로 세분화하여 모듈 간의 관계를 구조적으로 설계하는 과정
모듈화 (Modularity)	- 모듈은 서브루틴, 하부 시스템, 소프트웨어 내 프로그램 혹은 작업 단위를 의미 - 소프트웨어를 기능 단위로 분해한 것으로, 모듈화된 시스템은 시스템을 모듈들의 집합으로 추상화한 것 → 재사용성의 증가

(2) 설계 모델링

1. 소프트웨어 설계 대상

구조 모델링
- 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링한다.
행위 모델링
- 소프트웨어의 구성 요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지를 모델링한다.

모델링(Modeling)

- 모델링을 통해 개발팀이 응용 문제를 이해하는 데 도움을 줄 수 있다.
- 개발 전체 단계에서 활용할 수 있다.
- 개발될 시스템에 대하여 여러 분야의 엔지니어들이 공통된 개념을 공유하는 데 도움을 준다.
- 절차적인 프로그램을 위한 자료 흐름도는 프로세스 위주의 모델링 방법이다.

2. 소프트웨어 설계 유형

구분 내용자료구조 설계(Data Structure Design)아키텍처 설계(Architecture Design)인터페이스 설계(Interface Design)프로시저 설계(Procedure Design)

구분	내용
자료구조 설계 (Data Structure Design)	- 요구 분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는 데 필요한 자료구조로 변환하는 과정 ex) 트리구조, 큐, 스텍
아키텍처 설계 (Architecture Design)	- 예비 설계 or 상위 수준 설계 - 소프트웨어 시스템의 전체 구조를 기술한다. - 소프트웨어를 구성하는 컴포넌트들 간의 관계를 정의한다.
인터페이스 설계 (Interface Design)	소프트웨어와 상호작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 기술한다.
프로시저 설계 (Procedure Design)	- 알고리즘 설계 - 프로그램 아키텍처의 컴포넌트를 소프트웨어 컴포턴트의 프로시저 서술로 변환하는 과정

상위 설계(기본 설계)

- 아키텍처 설계
- 데이터베이스
- 인터페이스 설계
- 하위 설계(상세 설계)
- 모듈 설계
- 시스템의 내적 동작
- 자료구조, 알고리즘 설계

3. 설계 방법

구분	내용
구조적 설계 (Structured Design)	- 소프트웨어에 요구된 기능, 자료 처리 과정, 알고리즘 등을 중심으로 시스템을 분해하여 설계하는 방식이다. (기능적 관점) - 시스템의 각 모듈은 최상위 기능에서 하위 계층으로 하향적 세분화한다.
자료구조 중심 설계	- 입출력 자료구조를 파악함으로써 소프트웨어 구조를 추출하는 방식 - Warnier-Orr, Jackson 등이 있다.
객체지향 설계 (Object-Oriented Design)	- 자료와 자료에 적용될 기능을 함께 추상화하는 개념이다. (객체 = 자료 + 기능) - 시스템은 객체의 모임이다. - Yourdon, Rumbaugh, Booch 등이 있다.
협약에 의한 설계 (Design by Contract)	- 클래스에 대한 여러 가정을 공유하도록 명세한 것 - 소프트웨어 컴포넌트에 대한 인터페이스 명세를 위해 선행 조건, 결과 조건, 불편 조건을 나타내는 설계 방법

📌 객체지향(클래스) 설계 원칙

1. SRP(Single Responsibility Principle, 단일 책임의 원칙)

‘무엇을’과 ‘어떻게’를 분리하여 변경을 제한시킨다.

객체는 하나의 책임(변경의 축)만을 가져야한다.

2. DIP(Dependency Inversion Principle, 의존 관계 역전의 원칙)

클라이언트는 구체 클래스가 아닌 인터페이스에 의존하여 변화에 대처한다.

클라이언트는 구체 클래스의 변화에 대해 알지 못해도 된다.

3. ISP(Interface Segregation Principle, 인터페이스 분리의 원칙)

클라이언트가 분리되어 있으면, 인터페이스도 분리된 상태여야한다.

클라이언트에 특화된 여러 개의 인터페이스가 하나의 범용 인터페이스보다 낫다.

4. OCP(Open-Closed Principle, 개발 폐쇄의 원칙)

기존 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계되어야한다.

5. LSP(Liskov Substitution Principle, 리스코프 대체 원칙)

기반 클래스는 파생 클래스로 대체 가능해야한다.

2. 소프트웨어 아키텍처

(1) 소프트웨어 아키텍처의 정의

소프트웨어 컴포넌트들과 그들의 외부적으로 보여지는 특성으로 그들 상호 간의 관계들로 구성되는 해당 시스템의 구조 또는 구조들이다.
소프트웨어의 골격이 되는 기본 구조로 품질 특성과 개발 진행 방법에 영향을 주며, 소프트웨어 개발을 성공으로 이끌기 위한 중요한 역할을 수행

소프트웨어 아키텍처 설계 과정

1. 설계 목표 설정
2. 시스템 타입 설정
3. 스타일 적용 및 커스터마이즈
4. 서브시스템의 기능, 인터페이스 동작 작성
5. 아키텍처 설계 검토

(2) 아키텍처의 역할

소프트웨어 아키텍처 설계에서는 개발 대상이 되는 소프트웨어의 비기능적인 성질을 검토하여 기본 구조를 정한다.
시스템 전체에 관련된 성징들을 이해하기 위한 체계를 제공
- 전체의 흐름, 통신 패턴, 처리규모와 성능, 실행 제어의 구조, 확장성(이용자 수와 프로세스 수가 증가했을 때에 유연하게 확장/대응할 수 있는 정도), 소프트웨어 전체에 관련된 일관성, 장래의 발전에 대한 전망, 입수 가능한 부품과 부품의 적합성 등
소프트웨어 아키텍처를 설계하여 문서화해 두었을 때의 장점
- 관여자들(소프트웨어 개발에 관련된 사람들) 사이의 의사소통 개선, 시스템의 해석(시스템 개발 초기에 Trade-off를 맞추기 위해 시스템의 해석이 필요), 소프트웨어의 재이용 등이 있다.

(3) 소프트웨어 아키텍처의 특성

간략성 : 이해하고 추론할 수 있을 정도의 간결성을 유지한다.
가시성 : 시스템이 포함해야 하는 것들을 가시화하여, 청사진을 제공한다.
추상화 : 시스템의 추상적인 표현을 사용한다. → 복잡도 관리

(4) 소프트웨어 아키텍처 스타일 패턴

MVC 패턴(Model View Controller Pattern)

모델(Model), 뷰(View), 제어(Controller) 구조라는 세 가지 다른 서브시스템으로 구성한다.

모델 서브시스템	도메인의 지식(데이터)을 저장/보관한다.
뷰 서브시스템	사용자에게 보여준다.
제어 서브시스템	사용자와의 상호작용을 관리한다.

사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문에 분리한다.
같은 모델에 대하여 여러 가지 부가적으로 필요한 상호작용 시스템을 위하여 적절한 구조이다.
MVC 모델은 사용자 인터페이스를 담당하는 계층의 응집도를 높이고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다.
뷰는 모델에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다.
제어는 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다.

클라이언트 - 서버 패턴(Client-Server Pattern)

클라이언트	- 사용자로부터 입력을 받아 범위를 체크한다. - 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집한다.
서버	- 트랜잭션을 수행한다. - 데이터의 일관성을 보장한다. - 클라이언트에게 서비스를 제공한다.
서비스의 요구	- 원격 호출 메커니즘이다. - CORBA나 Java RMI의 공통 객체 브로커가 있다.

계층 패턴(Layered Pattern)

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용한다.
추상화의 성질을 잘 이용한 구조이다.
예) OSI 7계층 구조
장점 : 각 층을 필요에 따라 쉽게 변경할 수 있다. / 단점 : 성능 저하를 가져올 수 있다.

파이프 필터 패턴(Pipe-Filter Pattern)🔥

서브시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브시스템에 보내는 작업이 반복된다.
서브시스템을 필터라고하고, 서브시스템 사이의 관계를 파이프라고 한다.

마스터-슬레이브 패턴(Master-Slave Pattern)

마스터와 슬레이브라는 두 부분으로 구성
마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산하고, 슬레이브가 반환한 결과값으로 최종 결과값을 계산한다.
데이터를 동시에 수집하는 동안 사용자 인터페이스 제어에 응답할 때 가장 일반적으로 사용한다.
일반적으로 실시간 시스템에서 사용
마스터 프로세스
- 일반적으로 연산, 통신, 조정을 책임
- 슬레이브 프로세스 들을 제어할 수 있다.

저장소 구조

서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경한다.
서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화한다.
ex) 급여 시스템, 은행 시스템과 같은 데이터베이스

(5) 소프트웨어 아키텍처 설계 품질 속성🔥

가용성 (Availability)	소프트웨어가 필요할 때 적절하게 작업을 수행할 준비가 되었는지를 판단
변경 용이성 (Modifiablility)	소프트웨어에 새로운 기능 추가, 오류 수정, 보안 강화, 성능 개선 등과 같은 변경이 용이한지 판단한다.
사용성 (Usability)	사용자가 얼마나 쉽게 사용할 수 있는가에 대한 척도이다.

3. 코드 설계

(1) 코드의 정의

코드란 파일 시스템을 체계화(데이터의 수집이나 분류, 집계 등을 용이하게 하기 위해)하기 위하여 처리 대상이 되는 주요 항목에 대하여 사용 목적에 따라 문자, 숫자, 기호를 사용하여 만들 것
- ex) 주민등록번호, 학번 등

(2) 코드의 기능

식별 기능	서로 다른 대상 항목을 구별할 수 있는 기능
분류 기능	대상 항목을 관련성에 따라 그룹별 처리가 가능한 기능
배열 기능	대상 항목들을 순서적으로 나열할 수 있는 기능

(3) 코드의 특징

고유성, 표준성, 확장성, 영속성이 있어야한다.
최소의 자릿수로 표현되어야한다.
간단/명료하고 데이터의 내용이 연상되면 사용이 용이하다.
컴퓨터 처리에 적합해야하고, 오류를 검출할 수 있어야한다.

(4) 코드의 종류

일련번호식 코드(순차 코드, Sequential Code)

발생순, 크기순, 가나다순 등에 따라 순차적으로 부여
일반적으로 코드가 간단하여 기계 처리에 적합하지만, 코드표가 있어야 코드가 나타내는 정보를 알 수 있다.
ex) 지명코드

블록 코드(Block Code) = 구분 코드

공통성 있는 것끼리 블록으로 묶어서 구분하며, 블록 내에서는 순차적으로 부여
예비 코드가 들어있는 것이 특징 예비코드의 크기에 따라 코드를 효율적으로 사용할 수 있다.
ex) 부서 코드

그룹 분류 코드(Group Classification Code)

코드화 대상 항목을 대분류, 중분류, 소분류로 구분하고, 각 그룹별 내에서 순차적으로 코드를 부여한다.
ex) 학번 코드, 사원번호 코드

10진 코드(Decimal Code)

10진법의 원리에 맞추어 대분류, 중분류, 소분류하여 부여한 코드이다.
ex) 도서 분류 코드

유효 숫자식 코드(표의 숫자 코드, Significant Digit Code)

대상 항목의 크기, 중량, 거리등을 그대로 사용하는 코드
대상 항목을 코드로 그대로 사용하므로 기계 처리가 좋지 않다.
현장에서의 사용 용이성이 매우 높다.
ex) 폭 450mm, 길이 700mm, 두께가 45mm인 철판 → 450700045 / 파이프

연상기호 코드(Mnemonic Code)

대상과 관계있는 문자나 숫자를 조합하여 만든 코드로, 상품명이나 거래처명에 많이 사용된다.
ex) W-TV 15” : 흑백 텔레비전 15인치

약자식 코드(Letter Type Code)

관습상 또는 제도적으로 널리 사용되는 문자를 그대로 사용하는 코드
ex) mg, kg : 무게 / mm, cm, km : 길이

4. 구조적 설계 도구

(1) 구조도(Structure Chart)의 개념🔥

자료구조도
시스템 기능을 몇 개의 기능으로 분할하여 모듈로 나타내고, 모듈 간의 인터페이스를 계층 구조로 표현한 도형
구조도에서 사각형은 모듈, 백색원의 화살표는 매개변수를 이용한 자료의 이동, 흑색원의 화살표는 실행의 방향을 나타내는 제어 흐름, 마름포는 선택, 곡선 화살표는 반복을 나타낸다.
구조적 설계 도구인 자료 구조도는 자료 흐름도를 변환 분석하여 만들 수 있다.
팬 인(Fan-In)🔥
- 특정 모듈을 직접 제어하는 모듈의 수
팬 아웃(Fan-Out)🔥
- 한 모듈에 의해 직접 제어되는 모듈의 수

(2) HIPO(Hieratchical Plus Input Process Output)

프로그램 논리의 문서화와 설계를 위해 도식적인 방법을 제공하며, 기능 표현 중심이다.
시스템의 분석 및 설계나 문서화에 사용되는 기법으로 계층을 구성하는 각 모듈별 실행 과정인 입력, 처리, 출력 기능을 나타낸다.
관람자에 따라 다른 도표 제공이 가능
프로그램의 전체적인 흐름 파악이 가능
하향식(Top-Down) 개발 기법(계층적 구조)이며, 문서의 체계화가 가능
프로그램의 변경 및 유지보수가 용이
논리적인 기술보다는 기능 중심의 문서화 기법으로 신뢰성은 조금 떨어진다.
HIPO 차트의 종류 : 가시적 도표 / 총체적 도표 / 세부적 도표

가시적 도표(=가시적 목차 도표)	- 시스템의 전체적인 흐름을 계층적으로 표현한 도표 - 눈에 잘 들어온다. - IPO를 나누지 않는다.
총제적 도표(=총괄 도표)	- 입력, 처리, 출력에 대한 기능을 계략적으로 표현한 도표 - 제목만 간략히
세부적 도표(=상세적 도표)	- 총제적 도표 내용을 구체적 모듈별 입력-처리-출력 도표로 표현

(3) PDL(Program Design Language)

구조적 영어 또는 의사코드라 불리는 자연 언의 단어를 이용하여 구조적 프로그래밍 언어의 문법으로 기술한 혼합 언어
구조적으로 설계된 프로그램을 자연어와 비슷하게 표현

(4) N-S(Nassi & Schneiderman)차트

Box Diagram, Chapin Chart
논리 기술에 중점을 둔 도형식 표현 도구
순차, 선택, 반복의 3가지 제어 구조를 표현
화살표나 GOTO문은 사용하지 않는다.
- 무조건 분기의 사용을 할 수 없다.
단일 출입구가 있는 프로그램 구조를 나타내기 편리하다.
도표로 그려야 하는 불편함이 있고, 수정이 쉽지 않다.
프로그램의 전체 구조 표현에는 부적합하다.

(4) Jackson Diagram

트리 구조의 다이어그램으로 프로그램의 입출력 자료를 이용하여 프로그램의 구조를 생성한다.
기본, 순차, 반복, 선택의 기호를 사용한다.

✅ 객체지향 설계

1. 객체지향 기법

(1) 객체지향의 개요

1996년 Simula 67 프로그래밍 언어를 개발하면서, 시스템의 한 구성원으로서 한 행위를 행할 수 있는 하나의 단위로 객체라는 개념을 사용했다.
객체지향 기법에서의 시스템 분석은 문제 영역에서 객체를 정의하고, 정의된 객체들 사이의 상호작용을 분석하는 것
객체지향 기법은 복잡한 시스템의 설계를 단순하게 한다.
시스템은 하나 또는 그 이상의 규정된 상태를 갖는 객체들의 집합으로 시각화될 수 있으며, 객체의 상태를 변경시키는 연산은 비교적 쉽게 정의된다.
코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경이 가능하다.
객체지향 소프트웨어는 그 구성이 분리되어 있기 때문에 유지보수가 쉽다.
동적 모델링 기법이 사용
데이터와 행위를 하나로 묶어 객체를 정의내리고 추상화시키는 작업

(2) 객체지향의 기본 개념

객체(Object)

현실세계에 존재할 수 있는 유/무형의 모든 대상
실제로 객체지향 프로그램 작성 시 기본 단위
속성과 메소드로 정의된다.

데이터(속성) + 연산(메소드) -> 객체

객체는 인터페이스인 공유 부분을 가지며, 상태(State)를 가지고 있다.

속성(Attribute)

객체가 가지고 있는 특성으로, 객체의 현재 상태를 의미한다.
속성은 객체의 상태, 성질, 분류, 식별, 수량 등을 표현한다.

클래스(Class)

데이터를 추상화하는 단위
공통된 행위와 특성을 갖는 객체의 집합
클래스라는 개념은 객체 타입으로 구현된 소프트웨어를 의미
동일한 타입의 객체들의 메서드와 변수들을 정의하는 템플릿(Template)이다.

메시지(Message)

한 객체가 다른 객체의 메서드를 부르는 과정으로, 외부에서 하나의 객체에 보내지는 메서드의 요구
일반 프로그래밍 과정에서 함수 호출에 해당

메소드(Method)

메소드는 객체가 어떻게 동작하는지를 규정하고, 속성의 값을 변경시킨다.
객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산을 정의한 것

인스턴스(Instance)

클래스로부터 만들어진 객체를 그 클래스의 인스턴스라고한다.
- 객체는 클래스에 의해 인스턴스화한다.
클래스로부터 객체를 만드는 과정을 인스턴스화(Instantiation)라고 한다.

다형성(Polymorphism)

같은 메시지에 대해 각 클래스가 가지고 있는 고유한 방법으로 응답할 수 있는 능력을 의미
두 개 이상의 클래스에서 똑같은 메시지에 대해 객체가 서로 다르게 반응하는 것
다형성은 주로 동적 바인딩에 의해 실현된다.
- 동적 바인딩이란? 실제 실행 중 또는 실행 과정에서 변경될 수 있는 바인딩을 말한다.
- 정적 바인딩이란? 실행 전(컴파일 시)에 바인딩되는 것

상속성(Ingeritance)

새로운 클래스를 정의할 때 기존의 클래스들의 속성을 상속받고, 필요한 부분을 추가시키는 방법
높은 수준의 개념은 낮은 수준의 개념으로 특정화한다.
하위 계층은 상위 계층의 특수화(Specialization) 계층이 되며, 상위 계층은 하위 계층의 일반화(Generaliztion) 계층이 된다.

캡슐화(Encapsulation)

객체를 정의할 때 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고, 필요한 인터페이스만을 밖으로 드러내는 과정
인터페이스가 단순화되고, 변경 발생 시 오류의 파급 효과가 적다.
소프트웨어 재사용성이 높아진다.

정보은닉(Infomaion Hiding)

객체의 상세한 내용을 객체 외부에 철저히 숨기고, 단순히 메시지만으로 객체와의 상호작용을 하게 하는 것
외부에서 알아야 하는 부분만 공개하고, 그렇지 않은 부분은 숨김으로써 대상을 단순화 시키는 효과가 있다.
유지보수와 소프트웨어 확장 시 오류를 최소화할 수 있다.

(3) 객체지향의 연관성

연관화 (Association)	- 관계성의 종류는 is-member-of이며, 링크 개념과 유사 - 공통의 의미를 서로 연관된 집단으로 표현하는 방법
분류화 (Classification)	- 관게성의 종류는 is-instance-of이며, 동일한 형의 특성을 갖는 객체들이 모여 클래스를 구성하는 것
집단화 (Aggregation)	- 관계성의 종류는 is-part-of이며, 서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 생성
일반화 (Generalization)	- 관계성의 종류는 is-a이며, 객체들에 있어 공통적인 성질들을 상위 객체로 정의한다.

2. 디자인 패턴

(1) 디자인 패턴(Design Pattern)의 개요

UML과 같은 일종의 설계 기법이며, UML이 전체 설계 도면을 설계하다면, 디지아니 패턴은 설계 방법을 제시한다.
객체지향 소프트웨어 시스템 디자인 과정에서 자주 접하게 되는 디자인 문제에 대한 기존의 시스템에 적용되어 검증된 해법의 재사용성을 높여 쉽게 적용할 수 있도록 하는 방법론
여러 가지 상황에 적용될 수 있는 탬플릿과 같은 것이며, 문제에 대한 설계를 추상적으로 표현한 것
1990년대 초반 Erich Gamma에 의해 첫 소개된 이후 1995년에 Gamma, Helm, John, Vlissides 네 사람에 의해 집대성되었고, 이것이 GoF의 디자인 패턴으로 널리 알려졌다.

(2) 디자인 패턴의 특성

객체지향 방법론의 가장 큰 장점인 재사용성과 모듈성을 극대화시켜 이를 적용하면 시스템 개발은 물론 유지보수에도 큰 효과가 있다.
디자인 패턴은 개개의 클래스, 인스턴스, 컴포넌트들의 상위 단계인 추상 개념을 확인하고 특정짓는다.
상위 단계에서 적용될 수 있는 개념이며, 시스템 구조를 재사용하기 쉽게 만들 수 있다.

(3) 디자인 패턴의 구성 요소

패턴의 이름과 구분 패턴에서 사용하는 이름과 패턴의 유형

패턴의 이름과 구분	패턴에서 사용하는 이름과 패턴의 유형
문제 및 배경	패턴이 사용되는 분야, 배경 그리고 해결하는 문제를 의미
솔루션	패턴을 이루는 요소들/관계/협동 과정을 말함
사례	간단한 적용 사례가 필요
결과	패턴을 사용하면 얻게 되는 이점이나 영향
샘플 코드	패턴이 적용된 원시 코드

(4) 디자인 패턴의 장점

많은 전문가의 경험과 노하우를 별다른 시행착오 없이 얻을 수 있다.
실질적 설계에 도움이 된다.
쉽고 정확하게 설계 내용을 다른 사람과 공유할 수 있다.
기존 시스템이 어떤 디자인 패턴을 사용하고 있는지를 기술함으로써, 쉽고 간단하게 시스템을 이해할 수 있다.
소프트웨어 구조 파악이 용이하다.
객체지향 설계 및 구현의 생산성을 높이는데 적합하다.
재사용을 위한 개발 시간이 단축된다.

(5) 디자인 패턴의 분류와 종류

생성 패턴 (Creational Pattern)	- 객체 인스턴스 생성을 위한 패턴으로, 클라이언트와 그 클라이언트에서 생성해야 할 객체 인스턴스 사이의 연결을 끊어주는 패턴 - 객체의 생성 방식을 결정하는 데 포괄적인 솔루션을 제공하는 패턴 - 종류 : 추상 팩토리(Abstract Factory), 빌더(Builder), 팩토리 메소드(Factory Method), 프로토타입(Prototype), 싱글턴(Singleton) 등
구조 패턴 (Structural Pattern)	- 다른 기능을 가진 객체가 협력을 통해 어떤 역할을 수행할 때, 객체를 조직화시키는 일반적인 방식을 제시한다. - 클래스와 객체가 보다 큰 구조로 구성되는 방법에 대해 해결안을 제시 - 종류 : 어댑터(Adapter), 브리지(Bridge), 컴포지트(Composite), 데코레이터(Decorator), 다이나믹 링키지(Dynamic Linkage), 퍼샤드(Facade), 플라이웨이트(FlyWeight), 프록시(Proxy), 가상 프록시(Virtual Proxy) 패턴 등
행위 패턴 (Behavioral Pattern)	- 객체의 행위를 조직화(Organize), 관리(Manage), 연합(Combine)하는 데 사용되는 패턴 - 객체 간의 기능을 배분하는 일과 같은 알고리즘 수행에 주로 이용 - 종류 : 책임 연쇄(Chain of Responsibility), 커맨드(Command), 인터프리터(Interpreter), 이터레이터(Iterator), 미디에이터(Mediator), 메멘토(Memento), 옵저버(Observer), 스테이트(State), 스트래티지(Strategy), 탬플릿 메소드(Template Method), 비지터(Visitor) 등

저작자표시 비영리 변경금지