2022. 6. 4. 12:18ㆍ소프트웨어 공학
디자인 패턴이란
아키텍처 설계 수준보다 낮은 수준의 설계 문제에 재사용 가능한 솔루션 제공
디자인 패턴 혜택
- 쉽게 재사용 가능
- 개발 시간 단축
- SW구조 파악 용이
- 설계 관련 지식 정리됨
- 개발자 간 의사소통 원할
- 객체지향 설계 원리를 잘따르게 됨
디자인 패턴 종류
생성 패턴 : 객체를 생성하는데 관련된 패턴
- 객체의 생성과 조합을 캡슐화
- 특정 객체가 생성,변경 되어도 프로그램 구조에 영향을 크게 안줌 : 유연성 제공
예 ) factory method: 생성할 객체의 클래스를 서브 클래스로 분리하여 객체 생성
- 팩토리 메서드를 포함하는 추상 클래스를 정의
- 하위 클래스에서 인스턴스를 생성
singleton: 한 클래스에 한 객체만 존재하도록 제한
- 클래스 자체를 정적 변수
- 생성자는 private로
- 유일한 객체를 접근하는 정적 메서드 포함
prototype: 기존 객체를 복제하여 생성
builder: 생성과 구현을 분리한 복학 객체
abstract factory: 동일한 주제와 관련된 다른 객체 집합 생성
-객체를 사용할 클라이언트에서 구체적인 객체 생성을 지정하는 책임을 분리
- 추상 인터페이스를 이용하여 관련 객체 패밀리 생성
구조 패턴 : 프로그램 구조에 관련된 패턴
- 자료구조나 인터페이스 구조 등
예 ) composite: 여러 개의 객체로 구성된 복합 객체와 단일 객체를 구별 없이 다룸
adapter: 인터페이스와 호환되지 않은 클래스를 중간에 맞춰줌
- 사용 가능한 서비스 인터페이스를 클라이언트가 예상하는 인터페이스에 맞게 조정
- 어댑터 : 서비스 제공 인터페이스를 클라이언트가 기대하는 인터페이스로 변환
bridge: 추상화 부분과 실제 구현 부분을 독립적으로 확장
decoration: 기존 객체에 동적으로 기능 추가
- 집합 관계외 위임을 이용
- 상속에 의한 추가
- 기능 조합 수 만큼 서브 클래스 필요
- 데코레이터 패턴 구성 요소
- 장식 대상 component 클래스와 확장 기능이 담긴 데코레이터
- 데코레이터 객체가 재귀 합성으로 component 객체 매핑
facade: 서브 시스템에 있는 인터페이스 집합에 대해 하나의 통합된 인터페이스 제공
flyweight: 다수 유사한 객체를 생성-조작 하는 비용을 절감
proxy: 실제 객체를 감사고 추가 기능을 제공, 실제 객체 접근 통제
행동 패턴 : 객체를 생성하는데 관련된 패턴
- 객체의 생성과 조합을 캡슐화
- 특정 객체가 생성,변경 되어도 프로그램 구조에 영향을 크게 안줌 : 유연성 제공
예 ) iterator: 반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 순차적 접근
- 클라이언트는 반복에 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근
observer: 클래스의 변화를 감지하여 다른 클래스에 알림
-옵저버들의 목록을 개체에 등록
- 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에 통지
- Subject 클래스 - 옵저버 목록을 유지, 변경을 고지
- Observer 클래스 - 변경을 통지 받고 접근을 요청
strategy: 알고리즘 군을 정의, 각각 하나의 클래스로 캡슐화 한 다음 선택하여 적용
template method: 상위 클래스에는 추상적으로 표현, 그 구체적인 내용을 하위 클래스에서 결정
visitor: 각 클래스의 데이터 구조로부터 처리 기능을 분리, 별도의 visitor 클래스 만듦
chain of responsibility: 책임들이 연결되어 있어 내가 책임을 못 질 것 같으면 다음 책임자에게 자동으로 넘김
command: 요청된 명령어를 캡슐화하여 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
mediator: 클래스 간의 복잡한 상호작용을 캡슐화하여 한 클래스에 위임해서 중재 처리
state: 동일한 동작을 객체 상태에 따라 다르게 처리
- 맥락과 상태를 별도로 구현
-융퉁성 달성을 위한 체계적이고 느슨한 결합 방식
memento: 클래스 설계 관점에서 객체의 정보를 저장
interpreter: 간단한 언어의 문법을 정의하고 해석에 사용, 문법 규칙을 클래스화
아키텍처 평가
아키텍처나 디자인 패턴의 속성, 강약점을 결정하는 방법
개발자가 선택한 아키택처가 기능적, 비기능적 품질 요구 사항을 모두 충족시킬 수 있음을 보증
- SAAM(Software Architecture Analysis Method) : 시나리오 기반 평가 방법
- 아키텍처가 시나리오를 실행할 수 있는지 여부를 결정
- 실행하지 못하는 경우 시나리오를 지원하도록 아키텍처를 변경
- 여러 이해 당사자를 통해 시나리오 도출
- 시나리오
- 직접: 시스템의 변경이 요구되지 않는 시나리오
- 간접 : 시스템의 변경이 요구되는 시나리오, 새로운 기능을 추가하거나 원하지 않는 기능을 삭제
-ATAM(Architecture Trade-off Analyisis Method)
- 여러 가지 품질 속성에 초점을 맞추어 평가
- 아키텍처의 Trade-off
- 설계 타헙점을 찾아냄