[정보처리기사] 디자인 패턴

1. 디자인 패턴

: 모듈의 세분화된 역할이나 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식.

=>기본형 코드들이 포함되어 있음.

=> 패턴에 변형을 가하면 유사한 형태의 다른 패턴으로 변화됨.

=> 생성, 구조, 행위 패턴으로 분류할 수 있다.

* 아키텍처 패턴과 차이점

아키텍처 패턴은 디자인 패턴보다 상위 수준의 설계에 사용되며, 전체 시스템의 구조를 설계하기 위한 참조 모델이다.

반면 디자인 패턴은 시스템의 컴포넌트들과 관계를 설계하기 위한 참조 모델이고, 몇몇 디자인 패턴은 아키텍처 패턴을 구현하는데 사용된다.

 

2. 생성 패턴 Creational Pattern

: 객체의 생성과 관련된 패턴 => 유연성 향상시킴

- 종류

a. 추상 팩토리 Abstract Factory

인터페이스를 통해 연관된 객체들의 그룹으로 생성해 추상적으로 표현

=> 클래스에 의존하지 않음

=> 연관된 서브 클래스를 묶어 한 번에 교체 가능 (인터페이스만 교체하면 되기 때문)

b. 빌더 builder

분리된 인스턴스를 조합하여 객체 생성

=> 객체의 생성 과정과 표현 방법을 분리

=> 동일한 객체 생성에서도 다른 결과를 만들어 낼 수 있음.

*인스턴스: 클래스에 속한 각각의 객체

c. 팩토리 메소드 Factory Method

객체 생성을 서브 클래스에서 처리

=> 상위 클래스는 인터페이스만 정의

d. 프로토타입 Prototype

원본 객체를 복제

=> 일반적인 방법. 비용이 큰 경우 주로 이용됨.

e. 싱글톤 Singleton

생성된 객체가 하나뿐임을 보장함

=> 객체를 어디서든 참조할 수 있지만, 여러 프로세스에서 동시에 참조 불가능(동기화?)

=> 불필요한 메모리 낭비 최소화

 

3. 구조 패턴 Structural Pattern

클래스나 객체들을 조합해 더 큰 구조로 만들 수 있게 하는 패턴.

- 종류

a. 어댑터 Adapter 

호환성 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환

=> 인터페이스가 일치하지 않을 때

b. 브리지 Bridge

구현에서 기능(추상층)을 분리

=> 구현과 기능이 독립적으로 확장될 수 있음

=> 기능과 구현을 별도의 클래스로

c. 컴포지트 Composite

복합 객체와 단일 객체를 구분 없이 다루는 패턴

=> 트리 구조로 객체 구성

d. 데코레이터 Decorator

객체 간의 결합을 통해 능동적으로 기능 확장

=> 객체를 덧붙이는 방식

e. 퍼싸드 Facade

상위에 통합 인터페이스를 구성해 서브 클래스들을 묶어서 간편하게 사용

=> 통합 인터페이스를 제공하는 Wrapper 객체 필요

f. 플라이웨이트 Flyweight

인스턴스를 가능한 한 공유해서 사용

=> 메모리 절약

g. 프록시 Proxy

접근이 어려운 객체에 접근할 때 인터페이스 역할 수행

=> 네트워크 연결, 대용량 객체로의 접근 등에 주로 이용됨.

 

4. 행위 패턴 Behavioral Pattern

객체들이 상호작용하는 방법이나 책임 분배 방법을 정의

=> 작업을 분배하여 결합도를 최소화시킴

- 종류

a. 책임 연쇄 Chain of Responsibility

Chain으로 이어진 객체 중 하나가 처리하지 못한 걸 다른 객체가 책임을 맡아줌.

b. 커맨드 Command

요청을 캡슐화해 저장 or 로그

* 캡슐화하면 재이용하기 쉽다.

=> 사용되는 커맨드들을 추상과 구현으로 분리해 단순화

c. 인터프리터

언어에 문법 표현을 정의

d. 반복자 Iterator

접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴

=>내부 표현 방법의 노출 없음

e. 중재자 Mediator

상호작용을 캡슐화

=> 의존성을 줄여 결합도 감소

f. 메멘토 Memento

특정 시점에서의 객체 내부 상태 객체화

=> 되돌리기 기능 구현하기 좋음

g. 옵서버 Observer

객체 상태가 변화하면 상속된 다른 객체들에게 상태 전달

=> 이벤트 Publish - 수신 Subscribe 형태가 분산 시스템에서 이루어짐

h. 상태 State

객체 상태 캡슐화

=> 상태에 따라 동일한 동작을 다르게 처리할 수 있음

i. 전략 Strategy

알고리즘을 캡슐화

* 캡슐화 하면 교환할 수 있다

=> 클라이언트에 영향 없이 알고리즘 변경 가능

j. 템플릿 메소드 Template Method

상위 클래스에서 틀을 정의하고, 하위클래스에서 구체화

=> 코드 양 감소, 유지보수 용이

k. 방문자 Visitor

데이터 구조에서 처리 기능을 분리해 별도의 클래스로 구성

=> 처리기능 필요할 때마다 방문