[소프트웨어 설계] 애플리케이션 설계

1. 공통 모듈 설계

1. 재사용

• 재사용은 시스템의 개발 시간/비용 절감을 위해 검증된 기능을 파악/재구성하여 시스템에 응용하기 위한 최적화 작업이다.
• 함수/객체, 컴포넌트, 애플리케이션 재사용
• 컴포넌트: 특정 기능을 수행하기 위해 독립적으로 개발되어 보급하고, 다른 부품과 조립되어 응용시스템을 구축하기 위해 사용되는 소프트웨어 프로그램

1. 공통 모듈

• 모듈: 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어
• 모듈화를 통해 분리된 시스템 기능으로 서브프로그램, 서브 루틴, 소프트웨어 내 단위 프로그램, 작업 단위 등과 같은 의미로 사용
• 모듈의 특징
  • 독립성
  • 다양한 조합
  • 재사용
  • 영향 최소화
• 공통 모듈: 전체 프로그램 기능 중 특정 기능을 처리할 수 있는 실행 코드, 자체적으로 컴파일이 가능하며 다른 프로그램에서 재사용 가능
• 공통 모듈 원칙
  • 정확성, 명확성, 완전성, 일관성, 추적성
• 모듈화: 프로그램이 효율적으로 관리될 수 있도록 시스템 분해/추상화 → 소프트웨어 제품의 성능을 향상/시스템 수정, 재사용, 유지보수를 쉽도록 하는 기법
• 모듈화 기법
  • 루틴: 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
  • 메인 루틴: 프로그램의 주요 부분, 전체의 개략적 동작 절차 표시; 서브 루틴을 호출
  • 서브 루틴: 메인 루틴에 의해 필요할 때마다 호출되는 루틴
• 모듈화 필요성: 모듈 크기가 너무 작아 모듈 개수가 많아지면 모듈 간 통합 비용이 많이 발생, 크기가 너무 커 모듈 당 개발 비용이 커짐
• 바람직한 모듈 설계 방안
  • 모듈 독립성/재사용성을 높이기 위해 결합도는 낮추고 응집도는 높임
  • 모듈의 복잡도/중복성을 높이고 일관성 유지
  • 모듈 기능은 예측이 가능해야 함, 지나치게 제한적이면 안 됨
  • 적당한 크기의 모듈 유지
  • 모듈 간 효과적 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 함
  • 유지보수 용이, 이식성 고려
• 모듈화 측정 지표
  • 응집도(Cohesion): 모듈의 내부 요소들의 서로 관련되어 있는 정도/모듈이 독립적인 기능으로 정의되어 있는 정도
  • 결합도(Coupling): 모듈 간 상호 의존하는 정도/모듈 간 연관 관계를 맺고 있는 정도
• 응집도 유형
  • 우연적<논리적<시간적<절차적<통신적<순차적<기능적
• 결합도 유형
  • 내용>공통>외부>제어>스탬프>자료
• 팬인/팬아웃
  • 팬인: 어떤 모듈을 제어하는 모듈의 수(현재 모듈이 제어 받음)
  • 팬아웃: 어떤 모듈에 의해 제어되는 모듈의 수(현재 모듈이 제어함)
  • 시스템 복잡도 최적화를 위해 팬인은 높게, 팬아웃은 낮게 설계해야 함

1. 설계 모델링

• 설계 모델링: 요구사항 분석 단계에서 규명된 필수 기능들의 구체적 구현 방법을 명시하는 기법/소프트웨어에 요구되는 기능/성능 조건을 만족하는 소프트웨어의 내부 기능, 구조, 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정
• 설계 모델링 원칙
  • sw 설계는 변경이 쉽도록 구조화되어야 함
  • 하나의 함수 안에 특정 기능을 수행하는 데 필요한 자료만 사용하도록 규제
  • 독립적/기능적 특성을 지닌 모듈 단위로 분할 설계
  • 계층적 구조
• 설게 모델링 유형
  • 구조 모델링: 프로시저, 데이터 구조, 모듈, 파일 구조
  • 행위 모델링: 입력/출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장 등
• sw 설계 유형
  • 자료구조 설계
  • 아키텍처 설계
  • 인터페이스 설계
  • 프로시저 설계
  • 협약에 의한 설계
• 소프트웨어 설계 원리
  • 상향식(bottom-up) 설계: 하위 기능부터 상위 기능으로 접근하는 방식, 인터페이스가 성립되어 있어야 기능 추가가 쉬움; 기존 컴포넌트를 조합하여 시스템 개발하는 경우 적합
  • 하향식(top-down) 설계: sw 설계 시 제일 상위 기능에서 시작해 하위 기능들로 분할해 가며 설계, 레벨이 낮은 데이터구조와 세부 사항은 설계 초기 단계에서 필요, 통합 검사 시 인터페이스가 이미 정의되어 있어 통합 간단; 시스템 명세가 명확한 경우, 모든 것을 새로 개발하는 경우 적합
• 코드 설계: 데이터 분류/조합을 쉽게 하기 위해 사물을 표현하는 코드를 설계하는 기법
• 코드의 기능
  • 표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출
• 코드 설계 종류
  • 연상 코드, 블록 코드(구분 코드), 순차 코드, 표의 숫자 코드, 십진 코드, 그룹 분류식 코드
• 코드 설계 절차
  • 코드화 항목 선정→코드화 목적 선정→코드화 대상 확인→코드화 범위 결정→코드 사용 기간 설정→코드화 항목의 특성 분석→코드화 방식 결정→문서화
• 코드 오류 종류
  • 사본, 전위, 생략, 첨가, 이중 전위 오류
• HIPO(Hierarchy Input Process Output): 시스템의 분석, 설계, 문서화에 사용되며 하향식 sw 개발을 위한 문서화 도구
  • 체계적 문서 관리 가능, 기호/도표 등을 사용해 보기 쉽고 이해 쉬움
  • 기능, 자료의 의존관계 동시 표현 가능
  • 변경/유지보수 용이
  • 시스템 기능을 고유 모듈들로 분할해 이들 간 인터페이스를 계층구조로 표현한 것을 HIPO 차트라 함
• HIPO 차트 종류
  • 가시적 도표
  • 총체적 도표
  • 세부적 도표

1. 소프트웨어 아키텍처

• sw 아키텍처: 여러 가지 sw 구성요소와 그 구성요소 특성 중 외부에 드러나는 특성, 구성요소 간 관계를 표현하는 시스템 구조; sw를 설계하고 전개하기 위한 지침/원칙
• sw 필요성: sw 아키텍처를 사용해 이해관계자 간 관점 조율, 시스템 최적화
• sw 아키텍처 4+1 뷰
  • 고객 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 sw적인 접근 방법
  • 4개의 분리된 구조로 구성되는 아키텍처 개념 제시, 이 4개 구조가 서로 충돌되지 않는지, 시스템 요구사항을 충족시키는지 증명하기 위해 유스케이스 사용
  • 구성요소
    • 논리 뷰: 시스템 기능적 요구사항이 어떻게 제공되는지 설명하는 뷰; 설계자/개발자 관점
    • 프로세스 뷰: 시스템 비기능적 속성으로서 효율적 자원 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰; 개발자/시스템 통합자 관점
    • 구현 뷰: 개발 환경 안에서 정적 sw 모듈의 구성을 보여주는 뷰; 컴포넌트 구조/의존성을 보여주고 컴포넌트에 관한 부가적 정보 정의
    • 배포 뷰: 컴포넌트가 물리적 아키텍처에 어떻게 배치되는지 매핑해서 보여주는 뷰; 물리적 시스템을 구성하는 각 부분들의 분산 형태와 설치에 초점
    • 유스케이스 뷰: 유스케이스/아키텍처를 도출/설계해 다른 뷰 검증; 외부 행위자에 의해 인식되는 시스템 기능 요구사항을 보여주는 데 초점; 사용자/설계자/개발자/테스트 관점
• sw 아키텍처 비용 평가 모델: 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델
• sw 아키텍처 비용 평가 모델 종류
  • SAAM(Software Architecture Analysis Method): 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능
  • ATAM(Architecture Trade-off Analysis Method): 아키텍처 품질 속성을 만족시키는지 판단/품질, 속성들의 이해 상충 관계 평가
  • CBAM(Cost Benefit Analysis Method): ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구 충족 비용 평가 모델
  • ADR(Active Design Review): 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
  • ARID(Active Reviews for Intermediate Designs): 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중
• sw 아키텍처 패턴: 외부에서 인식할 수 있는 특성이 담긴 sw 골격이 되는 기본 구조, sw 설계 시 참조할 수 있는 전형적 해결방식, 일반화되고 재사용 가능한 솔루션
• sw 아키텍처 패턴 유형
  • 계층화 패턴(Layered Pattern): 시스템을 계층화하여 구성, 하위 모듈들이 특정한 수준의 추상화 제공, 각 계층이 다음 상위 계층에 서비스 제공, 서로 마주보는 두 개의 계층 사이에서만 상호 작용 이루어짐
  • 클라이언트-서버 패턴: 하나의 서버와 다수의 클라이언트로 구성, 사용자가 클라이언트를 통해 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스 제공, 서버는 계속 클라이언트로부터 요청 대기
  • 파이프-필터 패턴: 데이터 스트림 생성/처리하는 시스템에서 사용하는 단방향 패턴, 서브 시스템이 입력 데이터 처리, 결과를 다음 서브 시스템으로 넘기는 과정 반복, 필터 컴포넌트는 재사용성/추가가 편리해 확장이 용이하지만 필터 간 데이터 이동에서 데이터 변환 오버헤드 발생
  • 브로커 패턴: 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 컴포넌트들은 원격 서비스 실행을 통해 상호작용 가능, 브로커가 컴포넌트 간 통신 조정 역할, 서버가 자신의 기능들을 브로커에 넘겨주며 클라이언트가 브로커에 서비스 요청 시 브로커가 클라이언트를 자신의 레지스트리에 있는 적합 서비스로 리다이렉션(예: 아파치 카프카)
  • 모델-뷰-컨트롤러 패턴: 대화형 애플리케이션을 모델, 뷰, 컨트롤 뷰 3개의 서브 시스템으로 구조화하는 패턴, 각 부분이 별도 컴포넌트로 분리되어 있어 서로 영향을 받지 않고 개발 작업 수행 가능
    • 모델: 핵심 기능, 데이터 보관
    • 뷰: 사용자에게 정보 표시
    • 컨트롤러: 사용자로부터 요청을 입력받아 처리, 모델-뷰 사이 전달자 역할
  • 마스터-슬레이브 패턴: 연산, 통신, 조정을 책임지는 마스터와 제어/동기화되는 대상인 슬레이브로 구성, 일반적으로 실시간 시스템에서 사용
• sw 아키텍처 품질 속성
  • 아키텍처 비용 평가를 위한 사항, 특정 품질에 대한 요구사항 명세, 최적 아키텍처를 선택하기 위한 핵심 요소
  • 시스템 품질 속성: 가용성, 변경 용이성, 성능, 보안성, 사용 편의성, 시험 용이성

2. 객체 지향 설계

1. 객체 지향

• 객체 지향: 실세계 객체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법
• 구성 요소
  • 클래스: 특정 객체 내의 변수, 메서드를 정의하는 일종의 틀; 객체 지향 프로그래밍에서 데이터를 추상화하는 단위, 하나 이상의 유사한 객체들을 묶어 하나의 공통된 특성을 표현, 속성은 변수/행위는 메서드 형태로 선언
  • 객체: 물리적/추상적으로 자신과 다른 것을 식별 가능한 대상; 클래스에서 정의한 것을 토대로 메모리에 할당, 객체마다 각각의 상태와 식별성을 가짐
  • 메서드: 클래스로부터 생성된 객체를 사용하는 방법, 객체가 메시지를 받아 실행해야 할 객체의 구체적 연산, 전통적 시스템의 함수 또는 프로시저에 해당하는 연산 기능
  • 메시지: 객체 간 상호작용을 위한 수단; 객체에게 어떤 행위를 하도록 지시하는 방법, 메시지는 객체에서 객체로 전달
  • 인스턴스: 객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체; 클래스에 속한 각각의 객체, 실제 메모리 상에 할당됨
  • 속성: 한 클래스 내에 속한 객체들이 가지는 데이터 값을 단위별로 정의한 것; 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값
• 객체 지향 기법
  • 캡슐화(Encapsulation): 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 기법
    • 결합도 낮춤, 재사용 용이
    • 인터페이스 단순화
    • 정보 은닉과 관계 깊음
    • 변경 발생 시 오류의 파급 효과 적음
  • 상속성(Inheritance): 상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법
  • 다형성(Polymorphism): 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
    • 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있음
    • 오버로딩: 매개변수의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법
    • 오버라이딩: 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 무시하고 재정의할 수 있는 기법
  • 추상화(Abstraction): 공통 성질을 추출해 추상 클래스를 설정하는 기법
    • 종류: 과정, 자료, 제어 추상화
  • 정보 은닉(Information Hiding): 코드 내부 데이터, 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술
    • 필요하지 않은 정보는 접근할 수 없도록 하여 한 모듈/하부 시스템이 다른 모듈 구현에 영향을 받지 않게 설계
    • 모듈 내부 자료구조, 접근 동작들에만 수정을 국한하지 않아 요구사항 등 변화에 대응 가능
    • 설계에서 은닉되어야 할 기본 정보로는 IP 주소와 같은 물리적 코드, 상세 데이터 구조 등이 존재
  • 관계성(Relationship): 두 개 이상의 엔티티 형에서 데이터를 참조하는 관계를 나타내는 기법
    • 연관화: is-member-of 관계; 클래스와 객체의 참조 및 이용 관계, 같은 계층에 속하는 클래스들 사이 상호 의존성을 보여주는 비계층적 관계성 나타냄
    • 집단화: is-part-of 관계, part-whole 관계; 서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 만듦, 일반화와 달리 상위 클래스 성질들이 하위 클래스로 상속되지 않음
    • 분류화: is-instance-of 관계; 공통 속성에 의해 정의된 객체 구성원들의 인스턴스
    • 일반화: is-a 관계; 클래스들 간 개념적인 포함 관계, 상위 클래스의 특성을 하위 클래스가 상속받음
    • 특수화: is-a 관계; 상위 클래스의 특성들을 상속받음과 동시에 하위 클래스에서 수정을 가하고 자기 자신의 고유한 특성을 갖는 관계
• 객체 지향 설계 원칙(SOLID)
  • 단일 책임의 원칙(Single Responsibility Principle, SRP): 하나의 클래스는 하나의 목적을 위해 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙
  • 개방 폐쇄 원칙(Open Close Principle, OCP): 소프트웨어 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다는 원칙
  • 리스코프 치환의 원칙(Liskov Substitution Principle, LSP): 서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)로 교체할 수 있어야 한다는 원칙
  • 인터페이스 분리의 원칙(Interface Segregation Principle, ISP): 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙, 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다는 원칙
  • 의존성 역전의 원칙(Dependency Inversion Principle, DIP): 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙
• 객체 지향 분석(Object Oriented Analysis): 사용자 요구사항을 분석해 요구된 문제와 관련된 모든 클래스, 속성/연산, 관계 등으로 나누어 분석하는 기법
  • 데이터-행위를 하나로 묶어 객체 정의, 추상화
  • 코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경 가능
• 객체 지향 방법론의 종류
  • OOSE(Object Oriented Software Engineering): 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용; 분석, 설계, 구현 단계로 구성, 기능적 요구사항 중심의 시스템
  • OMT(Object Modeling Technology): 그래픽 표기법을 이용해 소프트웨어 구성요소를 모델링하는 방법론; 분석 절차를 따라 모델링 진행
    1. 객체 모델링(정보 모델링): 시스템에서 요구하는 객체를 찾아 객체 간 관계 정의, 객체 다이어그램을 활용해 표현
    2. 동적 모델링: 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등 동적 행위 표현, 상태 다이어그램을 활용해 표현
    3. 기능 모델링: 프로세스들의 자료 흐름을 중심으로 처리과정을 표현, 자료 흐름도를 활용해 표현
  • OOD(Object Oriented Design): 설계 문서화 강조, 다이어그램 중심 개발 방법론
    • 분석과 설계의 분리가 불가능
    • 분석 시 이용된 객체 모델의 설계 시 적용

1. 디자인 패턴

• 디자인 패턴: sw 공학의 sw 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
  • 디자인 패턴을 참고해 개발할 경우 개발의 효율성, 유지보수성, 운용성 등의 품질이 높아지며 프로그램 최적화에 도움이 됨
• 디자인 패턴 구성요소
  • 패턴의 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드
• 디자인 패턴 유형
  • 생성 패턴: 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
  • 구조 패턴: 더 큰 구조 형성을 목적으로 클래스나 객체의 조합을 다루는 패턴
  • 행위 패턴: 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
• 디자인 패턴 종류
  1. 생성 패턴
     • Builder
       • 복잡한 인스턴스를 조립해 만드는 구조
       • 복합 객체 생성 시 객체를 생성하는 방법(과정)과 객체를 구현(표현)하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 디자인 패턴
       • 생성과 표기를 분리해 복잡한 객체 생성
     • Prototype
       • 처음부터 일반적 원형을 가져다 놓고 그것을 복사해 필요한 부분만 수정하여 사용하는 패턴
       • 객체 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정하며 객체 생성 시 갖추어야 할 기본 형태가 있을 때 사용되는 디자인 패턴
       • 기존 객체 복제로 새 객체 생성
     • Factory Method
       • 상위 클래스에서 객체 생성 인터페이스를 정의, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
       • 상위 클래스에서는 인스턴스를 만드는 방법만 결정, 하위 클래스에서 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩하여 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 특성을 갖는 디자인 패턴
     • Abstract Factory
       • 구체적 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
       • 이 패턴을 통해 생성된 클래스에서는 사용자에게 인터페이스(API) 제공, 구체적 구현은 Concrete Product 클래스에서 이루어지는 특징을 갖는 디자인 패턴
       • 동일 주제의 다른 팩토리 묶음
     • Singleton
       • 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며 생성 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
       • 한 클래스에 한 객체만 존재하도록 제한
  2. 구조 패턴
     • Bridge
       • 기능의 클래스 계층과 구현의 클래스 계층 연결, 구현부에서 추상 계층을 분리해 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
       • 구현뿐만 아니라 추상화된 부분까지 변경해야 하는 경우 활용
     • Decorator
       • 기존 구현된 클래스에 필요한 기능을 추가해 나가는 설계 패턴
       • 기능 확장이 필요할 때 객체 간 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주어 상속의 대안으로 사용하는 디자인 패턴, 객체의 결합을 통해 기능을 동적으로 유연하게 확장
     • Facade
       • 복잡한 시스템에 대해 단순한 인터페이스를 제공함으로써 사용자-시스템 간/시스템-시스템 간 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴
       • 오류에 대한 단위별 확인 가능, 사용자 측면에서 단순한 인터페이스 제공을 통해 접근성을 높일 수 있는 디자인 패턴
       • 통합 인터페이스 제공
     • Flyweight
       • 다수 객체로 생성될 경우 모두가 갖는 본질적 요소를 클래스화하여 공유함으로써 메모리 절약, 클래스의 경량화를 목적으로 하는 디자인 패턴
       • 여러 개의 가상 인스턴스를 제공해 메모리 절감
     • Proxy
       • 실체 객체에 대한 대리 객체로 실체 객체 접근 이전에 필요한 행동을 취할 수 있게 만듦
       • 미리 할당하지 않아도 상관없는 것들을 실제 이용할 때에 할당하게 하여 메모리 절약
       • 실체 객체를 드러나지 않게 하여 정보 은닉 역할 수행
       • 특정 객체로의 접근 제어 용도로 사용
     • Composite
       • 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 하는 패턴
       • 복합 객체와 단일 객체를 동일하게 취급
     • Adaptor
       • 기존 생성된 클래스를 재사용 가능하도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴
       • 상속을 이용하는 클래스 패턴, 위임을 이용하는 인스턴스 패턴의 형태로 사용
       • 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움
  3. 행위 패턴
     • Mediator
       • 객체 지향 설계에서 객체 수가 너무 많아지는 경우 서로간 토인을 위해 복잡해질 수 있음 → 가장 중요한 느슨한 결합 특성을 해칠 수 있으므로 중간에 이를 통제하고 지시할 수 있는 중재자를 두고, 중재자에게 모든 것을 요구하여 통신 빈도수를 줄여 객체 지향 목표를 달성하게 해 주는 디자인 패턴
       • 상호작용의 유연한 변경 지원
     • Interpreter
       • 언어의 다양한 해성, 구체적 구문의 분리와 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석 가능하도록 하는 디자인 패턴
       • 문법 자체를 캡슐화하여 사용
     • Iterator
       • 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체에 들어 있는 모든 항목에 반복자를 사용해 접근할 수 있는 디자인 패턴
       • 내부구조를 노출하지 않고 복잡 객체의 원소를 순차적으로 접근 가능하게 해 주는 행위 패턴
     • Template Method
       • 작업 처리의 일부분을 서브 클래스로 캡슐화, 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
       • 일반적으로 상위 클래스에는 추상 메서드를 통해 기능 골격 제공, 하위 클래스의 메서드에는 세부 처리를 구체화하는 방식으로 사용하여 코드 양 절감, 유지보수 용이
     • Observer
       • 한 객체의 상태가 바뀌면 그 객체에 의존하는 객체들에게 연락, 자동으로 내용이 갱신되는 방법
       • 일대다 의존성을 가지며 상호작용하는 객체 사이에서 가능하면 느슨하게 결합하는 디자인 패턴
       • 객체 상태 변화에 따라 다른 객체의 상태도 연동, 일대다 의존
     • State
       • 객체 상태를 캡슐화로 클래스화, 그것을 참조하게 하는 방식
       • 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경하여 변경 시 원시 코드의 수정을 최소화할 수 있고 유지보수 편의성을 갖는 디자인 패턴
     • Visitor
       • 각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클래스 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴
       • 객체 구조는 변경하지 않고 기능만 따로 추가하거나 확장할 때 사용
       • 특정 구조를 이루는 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원
     • Command
       • 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성 높은 클래스를 설계하는 패턴, 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 갖는 디자인 패턴
       • 요구사항 그대로 캡슐화
     • Strategy
       • 알고리즘 군을 정의, 같은 알고리즘을 각 하나의 클래스로 캡슐화하고 필요할 때 서로 교환해 사용할 수 있게 하는 패턴
       • 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 디자인 패턴
       • 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환
     • Memento
       • 클래스 설계 관점에서 객체 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴
       • Undo 기능 개발 시 사용
     • Chain of Responsibility
       • 정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능함 → 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인 패턴
       • 한 요청을 2개 이상의 객체에서 처리
• 디자인 패턴의 장단점
  • 장점
    • 요구사항 변경에 따른 소스코드 변경 최소화
    • sw 코드의 품질 향상
    • 설계 변경 요청에 대한 유연한 대처 가능
    • 범용적 코딩 스타일 적용
    • 개발자 간 원활한 의사소통
    • 재사용을 통한 개발 시간 단축 가능
    • sw 구조 파악 용이
    • 객체 지향 설계 및 구현의 생산성 높이는 데 적합
    • sw 품질, 생산성 향상
  • 단점
    • 객체 지향 설계/구현 위주의 사용
    • 초기 투자 비용의 부담