패턴이 나오게 된 문제 상황
각 상태에 따라 행동을 다르게 하고 싶은 경우 이를 상태 변수를 통해 해결하고자 함
=> 우리가 정의하는 행동마다 어떤 상태인지를 구별하고(조건문) 이에 따라 어떤 작업을 수행할지 정의해야 함
public class GumballMachine {
// 상태 변수로 표현
final static int SOLD_OUT = 0;
final static int NO_QUARTER = 1;
final static int HAS_QUARTER = 2;
final static int SOLD = 3;
int state = SOLD_OUT;
int count = 0;
public GumballMachine(int count) {
this.count = count;
if (count > 0)
state = NO_QUARTER;
}
//행동을 메소드로 구현, 각 상태에 따른 동작 정의해야함
public void insertQuarter() {
if (state == HAS_QUARTER)
System.out.println("You can't insert another quarter");
else if (state == SOLD_OUT)
System.out.println("You can't insert a quarter");
System.out.println("The machine is sold out");
else if (state == SOLD)
System.out.println("Please wait, already giving you a gumball");
else if (state == NO_QUARTER) {
state = HAS_QUARTER;
System.out.println("You inserted a quarter");
}
}
}
이렇게 작성시에 코드를 확장할 때에 수정사항이 많이 발생함, OCP 위반
상태가 하나 늘어날 때 모든 동작을 고쳐야함
변화하는 부분을 캡슐화해라 + 상속(Inheritance)보다는 구성(Composition)을 사용해라
=> state가 변화하는 부분이고 이에 따라 행동이 달라지는 것이기에 State를 캡슐화해야함
=> State Interface를 만들고 이를 State 클래스로 만들고 모든 행동을 담음으로써 현재 State클래스가 어떤 행동을 할지 책임지게 할 수 있음
State Pattern
internal state에 따라 객체가 행동을 다르게 하는 패턴
=> 객체의 클래스가 바뀌는 것과 같은 효과를 낼 수 있음
언제사용하는가?
object 행동이 state에 영향 받을 때
state들에 따른 행동을 구분하기 위해 조건문들을 사용할 때
행동에 맞추어서 메소드를 설계하면
매 메소드에 상태에 따른 동작이 각기 다르게 들어가야함
State 패턴을 적용하면
각각의 행동들이 state에 localized됨
기존에 행동들을 제어하던 조건문 제거
각 state에 대한 수정을 닫음으로 OCP 원칙 준수
직관성 개선
단점: State 만큼 객체가 늘어남
vs Strategy 패턴
Strategy 패턴과 유사하다 못해 class diagram을 보면 구별 못함
구조적으론 같지만 다르다
왜 why? 의도가 다르다
패턴을 적용하지 않았을 경우
strategy의 경우 공통된 부분은 두고 하위 클래스를 만들어(subclassing) 문제를 해결하고자 함
state의 경우 conditional state를 보고 행동을 다르게 적용했을 것
Who defines the state transitions?
- ContextClass :간단한 경우
- ConcreteState Classes : 확장성 고려하면 이게 정석
When are the ConcreteState objects created?
- 필요할때
- 처음에 쭉 만든다
'독서 기록 > 디자인패턴' 카테고리의 다른 글
[디자인패턴] 헤드퍼스트 디자인패턴 Chap.3 (Feat. 데코레이터 패턴) (0) | 2022.11.01 |
---|---|
[디자인 패턴] Composite Pattern (0) | 2022.10.24 |
[디자인패턴] Iterator 패턴 (0) | 2022.10.24 |
[디자인 패턴] SOLID 원칙 (0) | 2022.10.18 |
[디자인 패턴] 중재자 패턴 vs 옵저버 패턴 (0) | 2022.10.17 |
댓글