Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
Tags
- appcompatacitivity
- http 역사
- NestedScrollView
- http발전과정
- 리사이클러뷰풀
- apk 빌드 과정
- 안드로이드
- AAC
- 상태관리
- 프로세스
- 자이고트
- 뷰홀더
- 절대 주소
- 디자인 패턴
- DiffUtil
- flutter
- Dispatchers
- Kotlin
- 리사이클러뷰
- GetX
- viewModelScope
- AsyncListDiffer
- appcompatactivity
- 운영체제
- recyclerview
- 플로이드워셜
- 데코레이터 패턴
- 물리 메모리
- 내부 단편화
- Android
Archives
- Today
- Total
hong's android
[디자인 패턴] 상태 패턴 본문
상태 패턴
객체의 내부 상태가 바뀜에 따라 객체의 행동을 바꿀 수 있다.
직접 상태를 체크하고 상태에 따라 행동을 변경하는 것이 아니라
상태를 객체화하여 상태가 행동을 할 수 있도록 위임하는 패턴이다.
기존엔 객체의 상태를 저장하고, 변경하기 위해서 상태 별 상수 값을 만들어서 상태 변수에 저장했다.
그리고 어떠한 행동이 일어날 때마다 해당 상태에 맞게끔 해당 행동 메소드를 호출했다.
하지만 만약 상태가 추가, 변경 될수록 상태를 분기하는 코드를 수정해야 하고 OCP원칙에 따라 변경에 닫혀있고 확장에 열려있어야 하는데 이를 위반한다.
아래 블로그에 문제점에 대해 잘 정리되어 있다.
https://velog.io/@y_dragonrise/디자인-패턴-상태-패턴State-Pattern
Context는 state를 소유하고 클라이언트로부터 요청을 받는다. 그러면 Context의 request()는 소유하고 있는 state의
meathod1(), meathod2(), meathod3() 을 호출한다. State인터페이스 형태의 state 변수에 다른 state1,2,3 객체를
저장하고 state1,2,3의 메소드를 호출하는 형태이다.
state에 변경사항이 생기거나, state를 추가할 때 context의 수정은 최소화할 수 있다.
✅ 디자인 패턴 구현 깃허브 주소
Reference.
1. 헤드퍼스트 디자인 패턴
'Design-Pattern' 카테고리의 다른 글
[디자인 패턴] 템플릿 메소드 패턴 (0) | 2023.03.21 |
---|---|
[디자인 패턴] 컴포지트 패턴 (0) | 2023.03.21 |
[디자인 패턴] 싱글톤 패턴 (1) | 2023.03.13 |
[디자인 패턴] 커맨드 패턴 (0) | 2023.03.13 |
[디자인 패턴] 팩토리 패턴 (0) | 2023.03.07 |