[소프트웨어공학] Design-Pattern

Preliminary design (상위설계)

: 요구사항을 데이터 및 소프트웨어 아키텍처로 변환

Detailed design (상세설계)

: 소프트웨어에 대한 자세한 데이터 구조 및 알고리즘 표현으로 아키텍처 개선

 

기술적 측면에서 설계

Data design

: 생성된 정보 영역 모델을 데이터 구조로 변환

Architectural design

: 소프트웨어의 주요 구조적 컴포넌트 간의 관계에 대한 정의

Procedural design

: 구조적 컴포넌트를 소프트웨어의 절차적 디스크립션으로 변환

Interface design

: 인간-기계 상호작용을 위한 배치 및 상호 작용 메커니즘의 확립

 

Design Patterns

• 객체지향 설계 산출물을 재사용 : 유용한 설계정보를 패턴으로 정의
• 특정 문제에 대한 반복되는 솔루션(노하우)을 일정한 형식으로 정의한 것

왜 설계 패턴?

• 설계자들간의 의사 소통의 수단
• 어플리케이션 의존적인 부분의 분리 : 확장성 증대
• 기존 모델의 품질 향상
• 클래스를 확장하지만 코드는 변경으로부터 감춤

 

Design Patterns응용

특정 클래스에서 객체 생성시 : 클래스 이름을 명시하면 구현에 종속됨. -> 객체를 직접 생성하지 않고 인터페이스를 호출

연산 의존성 : 특정 연산을 호출하면 처리방법이 연산에 의존 -> 컴파일 시점과 런타임 시점 모두 만족하는 요청 처리 방법 변경

플랫폼 의존성 : 플랫폼 의존적인 인터페이스는 재사용성이 저하됨 -> 제거하기 위한 인터페이스 생성

객체 구현 혹은 알고리즘 의존성 : 객체가 변경되면 응용 객체도 변경 -> 구현 객체와 응용 객체 분리

서브 클래스를 통한 기능 확장 : 상속 구조에 대한 이해 필요 -> 서브 클래스를 확장하지 않고, 다른 객체와의 합성을 통해 기능 생성

클래스 변경의 어려움 : 한 클래스 변경이 다수 클래스에 영향을 미칠 때 -> 인터페이스 클래스를 두어 변경 영향을 최소화

 

1. 생성패턴

: 객체 생성 관련 패턴, 객체 생성, 변경으로 인한 시스템 영향 최소화

factory method 패턴

객체를 생성하는 인터페이스와 실제 객체 생성 클래스를 분리

상위 클래스 : 인스턴스를 만드는 방법만 결정

하위 클래스 : 인스턴스를 생성

객체를 생성하는 시점은 알지만, 어떤 객체를 생성해야 할지 알 수 없을 때, 객체 생성을 하위 클래스에 위임하여 해결

 

singleton 패턴

: 정확히 하나의 요소만 갖는 집합

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

동일한 자원이나 데이터를 공유하여 처리하는 객체가 여러 개 만들어질 필 요가 없을 경우 주로 이용

<<singleton>> 으로 스테레오 타입 정의

 

prototype 패턴

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

처음부터 일반적인 prototype(인스턴스)을 만들어 놓고 그것을 복사한 후 필요한 부분만 수정

<<prototype>> 으로 스테레오 타입 정의

 

builder 패턴

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

객체를 생성하는 방법과 객체를 구현하는 방법으로 분리

abstract factory 패턴

: 여러 개의 concrete Product를 추상화시킨 것

구체적인 구현은 concreteProduct 클래스에서 이루어짐

사용자에게 인터페이스(API)를 제공하고, 인터페이스만 사용해서 부품을 조 립하여 만듦

 

2. 구조패턴

: 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램 구조 설계 패턴

: 클래스/객체들의 합성을 통해서 더 큰 구조를 생성

: 규모가 큰 복잡한 시스템의 구조를 변경이 용이하도록 지원

 

composite 패턴

: 부분(Part) – 전체(Whole) 상속구조를 갖는 트리 구조 패턴

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

재귀적인 구조를 만들기 위한 설계 패턴

사용 예시

- 디렉토리 구조를 표현하고자 할 때

- 회사의 조직도를 나타내고자 할 때

 

adapter 패턴

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

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

패턴 형태

• 상속을 이용한 어댑터 패턴 (클래스 adapter 패턴)
• 위임을 이용한 어댑터 패턴 (인스턴스 adapter 패턴)

 

decorator 패턴

: 기존에 구현되어 있는 클래스에 그때 그때 필요한 기능을 추가해 나가는 설계패턴

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

 

facade 패턴

: 몇 개의 클라이언트 클래스와 서브시스템의 클라이언트 사이에 facade 라는 객체를 세워놓음으로써 복잡한 관계를 정리한 것

모든 관계가 전면에 세워진 facade 객체를 통해서만 이루어질 수 있게 단순한 인터페이스를 제공

facade 패턴을 이용하면 클래스간의 의존 관계가 줄어들고 복잡성도 낮아짐

 

proxy 패턴

: Proxy : 대리인 (무언가를 대신해서 처리하는 것)

복잡하거나 생성하는데 오래 걸리는 객체를 좀 더 간단한 객체로 표현하기 위해 필요할 때까지 객체 생성을 보류

별도의 프로세스를 두어 운영하는 것

 

3. 행위패턴

: 반복적으로 사용되는 객체들의 상호작용을 패턴화

• 클래스/객체의 상호작용 방법과 책임에 대한 분산 방법
  • 객체의 기능은 변하지 않지만 일을 처리하는 방법이 달라질 때
  • 행위를 다른 객체로 옮기거나 알고리즘을 대체하는 경우
  • 메시지 교환과 관련된 것

iterator 패턴

: 반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근 (배열, 리스트, Set, Map 등)

데이터들의 집합체를 모두 동일한 인터페이스를 사용하여 조작 할 수 있게 하는 것

 

observer 패턴

: 어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보 해주는 것

어떤 일이 생기면 미리 등록한 객체들에게 상태 변화를 알려주는 역할

 

strategy 패턴

: 알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 함

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

알고리즘을 사용하는 곳과 알고리즘을 제공하는 곳을 분리시킨 구조로 알고리즘을 동적으로 교체 할 수 있음

 

template method 패턴

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

코드 양을 줄이고 유지보수를 용이하게 만드는 역할

유사한 서브 클래스가 존재할 때 매우 유용

 

chain of responsibility  패턴

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

자동으로 연결되는 구조

- (예) 학생 전화 상담

• 전화 받은 사람이 담당자가 달라서 전화번호만 알려주고 일단 전화 를 끊고 다시 거는 (a)정적 구조
• 담당자가 아닐 경우 전화를 돌려주 는 (b)동적 구조

 

mediator  패턴

: 중간에서 연결하고 통제하는 역할

중재자에게 모든 것을 요구하여 통신의 빈도수를 줄여 객체지향의 목표를 달성하게 해주는 것

 

memento  패턴

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

패턴 선택

• 패턴이 어떠한 문제를 해결하는지 명확히 이해한다.
• 패턴이 의도하는 것이 무엇인지를 확인한다.
• 비슷한 목적의 패턴을 모아서 이해한다.
• 재설계 혹은 패턴 적용이 가능한 부분을 식별한다.
  • 동일한 기능을 갖는 클래스 식별 및 확인
• 해당 패턴을 클래스 다이어그램과 매핑해 본다.
• 대체를 확정하고 패턴을 적용한다.
  • 필요한 인터페이스를 수정한다.