디자인 패턴

디자인 패턴이란

아키텍처 설계 수준보다 낮은 수준의 설계 문제에 재사용 가능한 솔루션 제공

디자인 패턴 혜택

- 쉽게 재사용 가능

- 개발 시간 단축

- 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

    - 설계 타헙점을 찾아냄