본문 바로가기
소프트웨어 공학

디자인패턴

by iskull 2021. 4. 30.
728x90

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

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

3. 동일한 문제 유형에 대해서 그 해결 방법에 대한 지식이나 노하우가 패턴 형태로 충붕히 일반화 된것

 

장점:

  -개발자 간의 원활한 의사소통

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

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

  -설계 변경 오청에 대한 유연한 대처

단점

  -객체지향 설계 / 구현 위주

  -초기 투자 비용 부담

 

명세 형식

이름 패턴은 이름과 타입을 가짐. 패턴의 타입은 생성, 구조, 행위 패턴으로 나뉜다
배경, 문제 패턴이 적용되는 상황 또는 다루려는 문제를 간단히 설명
솔루션 패턴의 구조적인 설계나 행위적인 설계를 기술. UML의 클래스 다이어그램이나 시퀀스 다이어그램으로 패턴에 참ㅇ여하는 각 클래스의 역할과 관계를 나타냄
혜택과 책임 패턴을 적용함으로써 얻는 이점과 잠재적인 문제점을 나타냄
가이드라인 패턴을 적용할 때 유용한 정보를 제공
관련 패턴 유사한 패턴이나 연관된 패턴을 제공하여 변형 또는 확장할 때 참고하도록 함

 

GOF의 디자인 패턴 구분

 

생성 패턴 기능 객체 생성 과정에 관한 패턴
종류 Factory Method
Singleton
Prorotype
Builder
Abstract Factory
구조 패턴 기능 클래스나 객체의 합성에 관한 패턴
종류 Adapter
Composite
Bridge
Decorator
Facade
Flyweight
Proxy
행위 패턴 기능 클래스나 객체듫이 상호작용하는 방법과 책임 분산 방법 정의
종류 Template Method
Interpreter
Iterator
Observer
Strategy
Visitor
Chain of Responsibility
Command
Mediator
State
Memento

 

생성 패턴

Factory Method

  1. factory: 인스턴스를 만드는 곳

  2. 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식.

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

 

Singleton

 특정 클래스의 객체가 오직 한 개만 존재하도록 보장, 즉 클래스의 객체를 하나로 제한

   -프로그래머의 '주의'에 의해서가 아닌 프로그램의 '보증'

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

 

Abstract Factory

. -추상적인 부품을 조합해 추상적인 제품을 만든다

  -부품의 구체적인 구현은 제외하고 인터페이스 (API)만을 이용해 부품을 조립하고 제춤으로 완성

구조 패턴(Composite pattern)

composite object:

  -부분-전체의 구조로 표현되는 조립 객체,

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

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

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

leaf: 내부에 다른 것을 포함할 수 없는 클래스(내용물에 해당)

Composite: Leaf나 다른 Composite을 넣을 수 있는 클래스

Component: Leaf와 Composite을 동일하게 취급할 수 있도록 하는 공통적인 상위 클래스

 

adapter pattern

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

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

  *instance adapter pattern의 경우 composite한 객체의 메서드 overriding불가

  - class adapter pattern

  - instance adapter pattern

Decorator patter

  -기능 확장이 필요할 때 상속의 대안으로 사용, 메서드 호출의 반환값에 변화를 주기 위해 중간에 decorator를 두는 패턴

Facade patter

  -몇 개의 클라이언트 클래스와 서브시스템의 클라이언트 사이에 facade라는 객체를 둬서 복잡한 관계를 정리(구조화)한 것

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

  - 의존도가 낮아진다.

  - 다음과 같은 효과가 필요할 때 사용한다.

      1. 복잡한 서브 시스템에 대해서 단순한 인터페이스가 필요할 때

      2. 서브 시스템에 대해 계층화가 필요할 때

      3. 서브시스템의 변경에 영향을 받고 싶지 않을때

 

Proxy pattern

. -제어 흐름을 조정하기 위한 목적으로 중간에 대리자를 두는 패턴

  - decoration pattern과 비슷한거 같으니 decoration pattern은 기능의 확장을 위해 사용하고 proxy pattern은 단순히 흐름 조정을 위해 사용한다.

행위 패턴

  Observer patter

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

subject

strategy pattern

. -다른 방법으로 문제를 해결할 수 있는 알고리즘으로 쉽게 교체할 수 있게 도와준다.

-strategy: 전략 메서드를 가신 전략 객체

-context: 전략 객체의 사용자/소비자

 

Template Method

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

Mediator patter

- 다수의 객체들 사이에 다수의 관계가 존재할 때 중재자 역할의 객체를 이용해 관계를 축소 시키는 패턴

 

'소프트웨어 공학' 카테고리의 다른 글

요구분석 - 요구사항의 표현  (0) 2021.05.03
요구분석  (0) 2021.05.03
소프트웨어 아키텍쳐  (0) 2021.04.27
상위 설계  (0) 2021.04.27
형상 관리  (0) 2021.03.21