커맨드
계산 작업에 대한 호출을 메시지가 아닌 객체로 표현한다.
값 객체
객체가 생성된 이후 그 값이 절대 변하지 않게 하여 별칭 문제가 발생하지 않게 한다.
널 객체
계산 작업의 기본 사례를 객체로 표현한다.
템플릿 메서드
계산 작업의 변하지 않는 순서를 여러 추상 메서드로 표현한다. 이 추상 메서드들은 상속을 통해 특별한 작업을 수행하게끔 구체화된다.
플러거블 객체
둘 이상의 구현을 객체를 호출함으로써 다양성을 표현한다.
플러거블 셀렉터
객체별로 서로 다른 메서드가 동적으로 호출되게함으로써 필요 없는 하위 클래스의 생성을 피한다.
//as-is 1
abstract class Report {
abstract void print();
}
//이후 상속 구현
//as-is 2
abstract class Report {
String printMessage;
Report(String printMessage) {
this.printMessage = printMessage;
}
//switch문으로 printMessage에 따라 다른 메서드 호출
}
//to-be
void print() {
Method runMethod = getClass().getMethod(printMessage, null);
runMethod.invoke(this, new Class[0]);
}글쎄...그냥 상속이나 스위치 쓰는게 낫다는 느낌이다. 내가 자바를 잘 몰라서 그런것일 수도 있지만 to-be의 코드는 잘 읽히지 않는다.
메서드를 한 개만 가지는 하위 클래스들이 여럿 존재하는 직관적인 상황에서 코드를 정리하기 위한 용도로만 사용해야 한다.
팩토리 메서드
생성자 대신 메서드를 호출함으로써 객체를 생성한다.
임포스터
현존하는 프로토콜을 갖는 다른 구현을 추가하여 시스템에 변이를 도입한다.
- 널 객체: 데이터가 없는 상태를 데이터가 있는 상태와 동일하게 취급할 수 있다.
- 컴포지트 객체: 객체의 집합을 단일 객체처럼 취급할 수 있다.
컴포지트
하나의 객체로 여러 객체의 행위 조합을 표현한다.
컴포지트 패턴을 적용하는 것은 일반적인 개념과 맞지 않을 수 있지만 코드를 훨씬 단순하게 만든다. 중복이 나타나는 순각 컴포지트를 도입해 보고 프로그램의 복잡함을 해결할 수 있는지 관찰해 보자.
수집 매개 변수
여러 객체에 걸쳐 존재하는 오퍼레이션 결과를 수집하기 위해 결과가 수집될 객체를 각 오퍼레이션의 매개 변수로 추가한다.
