- 소프트웨어 아키텍처의 설계
- 소프트웨어의 골격이 되는 기본 구조
- 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
- 소프트웨어 개발 시 적용되는 원칙과 지침이며, 이해 관계자들의 의사소통 도구로 활용
- 기본적으로 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결과정
- 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스등을 결정함
- 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보은닉이 있음
- 모듈화
- 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미함.
- 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성을 향상
- 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이듬
- 추상화
- 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것
- 인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법
- 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있음
- 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있게 해줌
- 추상화의 유형
- 과정 추상화 : 자세한 수행과정 x, 전박적인 흐름만 파악
- 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의x, 데이터 구조를 대표할 수 있는 표현으로 대체
- 제어 추상화 : 이벤트 발생의 정확한 절차나 방법 x, 대표할 수 있는 표현으로 대체
- 단계적 분해
- Niklaus Witrth에 의해 제안된 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- 추상화의 반복에 의해 세분화
- 소프트웨어의 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행
- 정보 은닉
- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 어떤 모듈이 소프트웨어 기능을 수행하는데 반드시 필요한 기능이 있어 정보 은닉된 모듈과 커뮤니케이션할 필요가 있을 때는 필요한 정보만 인터페이스를 통해 주고 받음
- 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이
- 소프트웨어 아키텍터의 품질 속성
- 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계 되었는지를 확인하기 위해 품질 평가 요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화시켜 놓은 것
- 시스템 측면
- 성능 : 사용자 요청과 같은 이벤트가 발생했을 때, 이를 적절하고 빠르게 처리하는 것
- 보안
- 가용성 : 장애 없이 정상적인 서비스를 제공
- 기능성 : 사용자가 요구한 기능을 만족스럽게 구현하는 것
- 사용성 : 명확하고 편리하게 구현하는 것
- 변경 용이성
- 확장성
- 비즈니스 측면
- 시장 적시성
- 비용과 혜택 : 개발 비용을 더 투자하여 유연성이 높은 아키텍처를 만들 것인지를 결정하는 것
- 예상 시스템 수명
- 아키텍처 측면
- 개념적 무결성 : 구성요소들 간의 일관성을 유지
- 정확성, 완결성 : 제약사항들을 모두 충족
- 구축 가능성 : 모듈 단위로 구분된 시스템을 적절하게 분배하여 유연하게 일정을 변경할 수 있도록 하는 것
- 소프트웨어 아키텍처의 설계 과정
- 설계 목표 설정, 시스템 타입 결정, 아키텍처 패턴 적용, 서브 시스템 구체화, 검토 순으로 진행
-
아키텍처 패턴의 개요
- 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시
- 서브시스템들과 그 역할이 정의되어 있으며, 서브시스템 사이의 관계와 여러 규칙, 지침 등이 포함되어 있음
- = 아키텍처 스타일 또는 표준 아키텍처
- 아키텍처 패턴의 장점
- 개발 시간을 단축, 고품질의 소프트웨어를 생산
- 검증된 구조로 개발하기 때문에 안정적
- 의사소통이 간편
- 개발에 참여하지않은 사람도 손쉽게 유지 보수를 수행할 수 있음
- 시스템의 특성을 개발 전에 예측하는 것이 가능
- 종류에는 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴등이 있음
-
레이어 패턴
- 시스템을 계층으로 구분하여 구성하는 고전적인 방법 중의 하나
- 각각의 서브시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 됨
- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어지므로 변경 작업이 용이함
- 레이어 패턴은 특정 계층만을 교체해 시스템을 개선하는 것이 가능
- 대표적으로 OSI 참조모델이 있음
-
클라이언트-서버 패턴
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
- 사용자는 클라이언트와만 의사소통을 함. 사용자가 클라이언트를 통해 서버에 요청하고 클라이언트가 응답을 받아 사용자에게 제공하는 방식으로 서비스를 제공
- 서버는 클라이언트의 요청에 대비해 항상 대기 상태를 유지
- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적
-
파이프-필터 패턴
- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이함
- 필터 컴포넌트들을 재배치하여 다양한 파이프라인을 구축하는 것이 가능
- 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 주로 사용
- UNIX의 쉘
-
모델-뷰-컨트롤러 패턴
- 서브시스템을 3개의 부분으로 구조화하는 패턴
- 모델
- 서브시스템의 핵심 기능과 데이터를 보관
- 뷰
- 사용자에게 정보를 표시
- 컨트롤러
- 사용자로부터 받은 입력을 처리
- 패턴들의 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업을 수행할 수 있음
- 여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합
-
기타 패턴
- 마스터-슬레이브 패턴
- 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
- 마스터 컴포넌트는 모든 작업의 주체이고, 슬레이브 컴포넌트는 마스터 컴포넌트의 지시에 따라 작업을 수행하여 결과를 반환함
- 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 활용
- 브로커 패턴
- 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결
- 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합한 패턴
- 분산 환경 시스템에서 주로 활용
- 피어-투-피어 패턴
- 피어를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될 수도, 서비스를 제공하는 서버가 될수도 있는 패턴
- 클라이언트와 서버는 전형적인 멀티스레딩 방식을 사용
- 이벤트-버스 패턴
- 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
- 주요 컴포넌트 : 소스, 리스너, 채널, 버스
- 블랙보드 패턴
- 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태로, 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있음
- 해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴
- 음성 인식, 차량 식별, 신호 해석 등에 주로 활용
- 인터프리터 패턴
- 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성
- 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용 되어짐
- 마스터-슬레이브 패턴
-
객체지향의 개요
- 현실세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 기계적인 부품들을 조립하여 제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법을 말함
- 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용
- 소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있고 유지보수가 쉬움
- 복잡한 구조를 단계적, 계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리를 지원
- 현실 세계를 모형화하므로 사용자와 개발자가 쉽게 이해할 수 있음
- 주요 구성 요소와 개념에는 객체, 클래스, 캡슐화, 상속, 다형성이 있음
-
객체
- 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
- 데이터
- 개체가 가지고 있는 정보로 속성이나 상태, 분류 등을 나타냄
- 속성, 상태, 변수, 상수, 자료구조라고도 함
- 함수
- 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘
- 객체의 상태를 참조하거나 변경하는 수단이 되는 것으로 메소드, 서비스 ,동작, 연산이라고도 함
- 객체의 특성
- 독립적으로 식별 가능한 이름을 가지고 있음
- 객체가 가질 수 있는 조건을 상태라고 하는데, 일반적으로 상태는 시간에 따라 변함
- 객체와 객체는 상호 연관성에 의한 관계가 형성
- 객체가 반응할 수 있는 메시지의 집합을 행위하고 하며, 객체는 행위의 특징을 나타낼 수 있음
- 객체는 일정한 기억장소를 가지고 있음
- 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행
-
클래스
- 공통된 속성과 연산을 갖는 객체의 집합, 객체의 일반적인 타입을 의미
- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
- 클래스에 속한 각각의 객체를 인스턴스라 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화라고 함
- 동일 클래스에 속한 각각의 객체들은 공통된 속성과 행위를 가지고 있으면서, 그 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러 가지 객체를 나타내게 됨
- 최상위 클래스는 상위 클래스를 갖지 않는 클래스를 의미
- 슈퍼 클래스는 특정 클래스의 상위 클래스이고, 서브 클래스는 특정 클래스의 하위 클래스를 의미
-
캡슐화
- 데이터와 데이터를 처리하는 함수를 하나로 묶는 것을 의미
- 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐되어 외부에서의 접근이 제한적이기 때문에 외부 모듈의 변경으로 인한 파급 효과가 적음
- 캡슐화된 객체들은 재사용이 용이
- 객체들 간의 메시지를 주고받을때 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고,객체 간의 결합도가 낮아짐
-
상속
- 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 상속을 이용하면 하위 클래스는 상위 클래스의 모든 속성과 연산을 자신의 클래스내에서 다시 정의하지 않고서도 즉시 자신의 속성으로 사용할 수 있음
- 상위 클래스의 속성과 연산을 하위 클래스가 사용할 수 있기 때문에 객체와 클래스의 재사용, 즉 소프트웨어의 재사용을 높이는 중요한 개념
- 다중 상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것
-
다형성
- 메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력을 의미
- 객체들은 동일한 메소드명을 사용하며 같은 의미의 응답을 함
- 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 하는 것
-
모듈의 개요
- 모듈은 모듈화를 통해 준비된 시스템의 각 기능들로, 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용됨
- 모듈은 단독으로 컴파일이 가능하며, 재사용 할 수 있음
- 모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립됨을 의미하는 것으로, 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어짐
- 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 함
-
결합도
- 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미
- 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움
- 종류에는 자료 결합도, 스탬프 결합도, 제어 결합도, 외부 결합도, 공통 결합도, 내용 결합도가 있음
- 결합도의 정도
- 자료 < 스탬프 < 제어 < 외부 < 공통 < 내용
- 자료 결합도
- 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
- 매개 변수나 인수로 데이터를 넘겨주고, 처리 결과를 다시 돌려주는 방식
- 가장 바람직한 결합도
- 스탬프 결합도
- 모듈간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
- 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도
- 자료 구조의 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미침
- 제어 결합도
- 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도
- 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우에 발생
- 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 하위 모듈이 상위 모듈에게 처리 명령을 내리는 권리 전도현상이 발생
- 외부 결합도
- 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할떄의 결합도
- 참조되는 데이터의 범위를 각 모듈에서 제한할 수 있음
- 공통 결합도
- 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
- 내용 결합도
- 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
- 한 모듈에서 다른 모듈의 내부로 제어가 이동하는 경우에도 내용 결합도에 해당
-
응집도
- 정보 은닉 개념을 확장한 것, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미함
- 다양한 기준으로 모듈을 구성할 수 있으나 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮음
- 종류에는 기능적 응집도, 순차적 응집도, 교환적 응집도, 절차적 응집도, 시간적 응집도, 논리적 응집도, 우연적 응집도가 있음
- 응집도의 정도
- 기능 > 순차 > 교환 > 절차 > 시간 > 논리 > 우연
- 기능적 응집도
- 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
- 순차적 응집도
- 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
- 교환적 응집도
- 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
- 절차적 응집도
- 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 시간적 응집도
- 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
- 논리적 응집도
- 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
- 우연적 응집도
- 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도
-
팬인, 팬아웃
- 팬인은 어떤 모듈을 제어하는 모듈의 수
- 팬아웃은 어떤 모듈에 의해 제어되는 모듈의 수
- 시스템의 복잡도를 알 수 있음
- 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어 있다고 볼 수 있으나, 단일 장애점이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요
- 팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지 검토하고, 단순화 시킬 수 있는지 여부에 대한 검토가 필요
- 시스템의 복잡도를 최적화하려면 팬인은 높게, 팬아웃은 낮게 설계
-
코드의 개요
- 컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합 및 집계를 용이하게 하고, 특정 자료의 추출을 쉽게 하기 위해서 사용하는 기호
- 정보를 신속, 정확, 명료하게 전달할 수 있게 함
- 일정한 규칙에 따라 작성되며, 정보 처리의 효율과 처리된 정보의 가치에 많은 영향을 미침
- 예로 주민번호, 학번, 전화번호 등
- 코드의 주요 기능에는 식별 기능, 분류 기능, 배열 기능이 있음
- 식별 기능 : 데이터 간의 성격에 따라 구분이 가능
- 분류 기능 : 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화 할 수 있음
- 배열 기능 : 의미를 부여하여 나열할 수 있음
-
코드의 종류
- 순차코드
- = 순서 코드, 일련 번호 코드
- 블록코드
- 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법, 구분 코드
- = 구분 코드
- 10진코드
- = 도서 분류식 모드
- 그룹 분류 코드
- 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법
- 연상 코드
- 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나문자, 기호를 이용하여 코드를 부여하는 방법
- 표의 숫자 코드
- 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법
- = 유효 숫자 코드
- 합성 코드
- 필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 만드는 방법
- 순차코드
-
코드 부여 체계
- 이름만으로 개체(모듈, 컴포넌트, 인터페이스)의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
- 각 개체에 유일한 코드를 부여하여 개체들의 식별 및 추출을 용이하게 함
- 코드를 부여하기 전에 각 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함
- 코드 부여 체계를 담당하는 자는 코드의 자릿수와 구분자, 구조 등을 상세하게 명시해야 함
-
디자인 패턴의 개요
- 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미
- 재사용할 수 있는 기본형 코드들이 포함되어 있음
- 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적
- 한 패턴에 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화되는 특징이 있음
- GoF라고 불리는 에릭 감마, 리타드 헬름, 랄프 존슨, 존 블리시디스가 처음으로 구체화 및 체계화
- GoF의 디자인 패턴은 수많은 디자인 패턴들 중 가장 일반적인 사례에 적용될 수 있는 패턴들을 분류하여 정리함으로써, 지금까지도 소프트웨어 공학이나 현업에서 가장 많이 사용됨
- GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨
-
아키텍처 패턴 vs 디자인 패턴
- 아키텍처가 더 상위 수준의 설계에 사용
- 아키텍처 패턴은 전체 시스템의 구조를 설계하기 위한 참조 모델이고, 디자인 패턴은 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델
- 몇몇 디자인 패턴은 특정 아키텍처 패턴을 구현하는데 유용하게 사용됨
-
생성 패턴
- 객체의 생성과 관련된 패턴으로 총 5개가 있음
- 객체의 생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더해줌
- 종류
- 추상 팩토리
구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현 - 빌더
작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성
객체의 생성과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음 - 팩토리 메소드
객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당 - 프로토타입
원본 객체를 복제하는 방법으로 객체를 생성하는 패턴 - 싱글톤
하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없음
- 추상 팩토리
-
구조 패턴
- 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
- 구조가 복잡한 시스템을 개발하기 쉽게 도와줌
- 종류
- 어댑터
호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환 해주는 패턴 - 브리지
구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
기능과 구현을 두 개의 별도 클래스로 구현 - 컴포지트
여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있음 - 데코레이터
객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현 - 퍼싸드
복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요 - 플라이웨이트
인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴 - 프록시
접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로이용
- 어댑터
-
행위 패턴
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
- 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와줌
- 종류
- 책임 연쇄
요청을 처리할 수 있는 개체가 둘 이상 존재하여 한 객체가 처리하지못하면 다음 객체로 넘어가는 형태의 패턴
요청을 처리할 수 있는 각 객체들이 고리로 묶여 잇어 요청이 해결될 때까지 고리를 따라 책임이 넘어감 - 커맨드
요청을 객체의 형태로 캡슐화 하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화 함 - 인터프리터
언어에 문법 표현을 정의하는 패턴
SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용 - 반복자
자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
내부 표현 방법의 노출 없이 순차적인 접근이 가능 - 중재자
수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴
객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음 - 메멘토
특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
Ctrl+Z와 같은 되돌리기 기능을 개발할 때 주로 이용 - 옵서버
한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
주로 분산된 시스템 간에 이벤트를 생성, 발행하고, 이를 수신해야 할 때 이용 - 상태
객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
객체 상태를 캡슐화하고 이를 참조하는 방식 - 전략
동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 - 템플릿 메소드
상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
코드의 양을 줄이고 유지보수를 용이하게 해줌 - 방문자
각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
분리된 처리 기능은 각 클래스를 방문하여 수행
- 책임 연쇄