오퍼레이션 패턴

오퍼레이션에 임무를 준다던지 하는 특징을 가지고 있는 패턴

일반적인 정의
오퍼레이션 - 클래스의 인스턴스가 요청할 수 있는 서비스의 명세
메소드 - 오퍼레이션을 구현한 것
알고리즘 - 입력을 전달받아 출력을 생성하는 프로시저

일반적인 오퍼레이션을 넘어

• 템플릿 메소드 패턴: 알고리즘을 메소드로 구현할 때 서브클래스 알고리즘의 일부 단계를 재정의할 수 있도록 하여 일부 단계의 정의를 미룰 때
• 상태 패턴: 각각의 클래스들이 서로 다른 상태를 나타내도록 오퍼레이션을 분배할 때
• Strategy 패턴: 구현을 교체 가능하도록 오퍼레이션을 캡슐화

템플릿 메소드 패턴

배경(문제상황-해결방안)

코드의 중복을 막기 위하여 하위 클래스들에게서 공통적인 부분을 추출하여 하나의 클래스로 정의하고자 할 때
하위클래스 확장을 제어하고 싶을 때 상위클래스에서 재정의될 부분을 지정하기 위해

기본 골격에 해당하는 부분을 따로 빼둔다
Primitive 메소드
- 개별적으로 차이가 발생하는 함수들
- Primitive Method가 특정 객체를 생성함

설명

사용되는 프로토콜에 따라 달라지는 함수들이 있기에 생겨났다.
객체지향의 '상속'의 개념을 잘 구현한 패턴이다.

특징

연산에서 알고리즘에 대한 기본 골격을 정의하고, 개별적인 함수구현은 하위클래스로 미룸
알고리즘의 기본 골격은 그대로 둔 채 알고리즘의 특정 단계를 하위클래스에서 재정의한다.

알고리즘 중에서 변하지 않는 부분을 상위 클래스에서 한번만 구현하고, 상황에 따라 변하는 부분은 하위 클래스들에 의해 구현한다.

코드 재사용을 위한 기본적으로 사용할 수 있는 방법이다. 일반적인 상속의 경우 하위클래스가 상위클래스의 함수를 호출하는데 반해, 템플릿메소드패턴에서는 상위클래스가 하위클래스가 구현한 함수를 호출한다.
Strategy pattern과 달리 알고리즘 전체를 바꾸는게 아닌, 일부만 변경하는 것이다.

primitive 오퍼레이션은 protected로 선언한다
primitive 오퍼레이션을 최소화한다

요소

• AbstractClass : 하위 클래스에서 구현해야 할 primitive 오퍼레이션들을 정의. 알고리즘에서 변하지 않는 부분 구현
• ConcreteClass : 템플릿 메소드에서 이용될 primitive operation들을 구현

구조

AbstractClass
변하지 않는 추상 primitive 오퍼레이션(하위 클래스에서 구현해야함)
알고리즘의 기본 골격을 구성하는 템플릿 메소드 구현
ㅅ
| 상속
|
ConcreteClass
변하는 부분

상태 패턴

배경(문제상황-해결방안)

객체의 행위가 해당 객체의 상태에 따라 달라질 때.
객체의 함수 코드가 객체의 상태에 따라 큰 부분의 조건문장으로 구성되어 있을 때(if 문장, switch 문장)

설명

객체의 내부 상태가 변경되었을 때 그에 따라 객체의 행위도 변경되게한다(마치 다른 클래스의 객체가 된 것 처럼)
커맨드 패턴과 유사
상태 고유의 동작을 국부화하고 동작을 각 상태에 분할
상태 변환을 외부에 노출
상태 객체는 공유

특징

요소

• Context : 현재 상태를 나타내는 ConcreteState 객체 reference를 갖음
• State : Context 객체의 현재 상태에 따라 다른 행위를 하는 함수들의 interface를 정의
• ConcreteState : 각 Class들은 Context 객체의 특정 상태에 따라 수행되는 행위들을 구현

구조

Strategy 패턴

배경(문제상황-해결방안)

새로운 요구를 다루는 법
변경을 위한 설계 원리
인터페이스에 의존하고, 구현에 의존하지 말 것
클래스 상속보다 객체(aggregation)을 애용할 것
설계에 변할 부분을 잘 고려할 것
재설계의 원인이 무엇일지에 초점

설명

설계에서 어떤 부분이 변하는지를 고려하여 알고리즘 패밀리를 정의하고 각각을 캡슐화한다
객체가 책임을 갖게한다
책임의 다른 구현을 다형성의 사용으로 명백하게 한다
개념적으로 같은 알고리즘의 다른 구현을 관리하기 위해 필요하다.

STEP
1. 변하는 부분 찾아 캡슐화
CalcTax 객체는 인터페이스를 정의
2. Aggregation
SalesOrder클래스가 CalcTax 객체를 포함하여 변경 처리하게 함

특징

클래스 상속보다 객체의 집합(aggregation)을 선호한다
클라이언트 -> 알고리즘 핸들링. 스트래티지를 바꿔끼는 구조

구조

장점

응집이 좋아짐
융통적
책임을 쉽게 교체할 수 있다

예시

국제 E-commerce 시스템의 주문 처리 시스템
-> 여러 국가의 주문을 처리하기 위함

• controller객체 : 판매 요청 처리
• SalesOrder : 주문 처리; 세금 계산; 판매 영수증 인쇄