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 |
Tags
- El
- 팩토리 메소드
- 추상 팩토리
- 함수형프로그래밍
- r
- 싱글톤
- a
- builderPattern
- designPattern
- Kotlin
- 디자인패턴 #
- Abstract Factory
- 디자인패턴
- 프로토타입 패턴
- 옵저버 패턴
- ㅋㅁ
- Singleton
- 추상팩토리패턴
- factory method
- 빌터패턴
- 코틀린
- F
- ㅓ
- Observer Pattern
- PrototypePattern
- Design Pattern
- Functional Programming
Archives
- Today
- Total
오늘도 더 나은 코드를 작성하였습니까?
Android app 아키텍처 원칙 본문
관심사의 분리
초보 개발자는 앱을 만들다보면 UI 기반의 클래스(Activity 또는 Fragment)에 많은 코드를 작성한다.
UI 기반의 클래스는 UI 및 운영체제와 상호작용을 처리하는 로직만 포함해야 합니다. 이러한 클래스를 최대한 가볍게 유지하여 많은 수명 주기 관련 문제를 피할 수 있다.
Activity 및 Fragment 구현은 소유의 대상이 아니며 Android OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐입니다. OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 제거할 수 있습니다. 만족스러운 사용자 환경과 더욱더 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋습니다
SOLID 원칙과 많은 부분이 부합되며 결국 관심사의 분리는 클래스간의 의존성을 줄이고 단일 책임을 지게 하는것이다.
관심사의 분리로 독립적 모듈화가 되면 재사용성 및 유지보수가 쉽다.
모델에서 UI 만들기
또 하나의 중요한 원칙은 모델에서 UI의 데이터 만들어야 한다는 것입니다. 가급적 지속적인 모델을 권장합니다. 모델은 앱의 데이터 처리를 담당하는 구성요소로, 앱의 View객체 및 앱 구성요소와 독립되어 있으므로 앱의 수명 주기 및 관련 문제의 영향을 받지 않습니다.
지속 모델이 이상적인 이유는 다음과 같습니다.
- Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
- 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다.
데이터 관리 책임이 잘 정의된 모델 클래스를 기반으로 앱을 만들면 쉽게 테스트하고 일관성을 유지할 수 있습니다.
'Android Jetpack Architecture > Introduction and Overview' 카테고리의 다른 글
객체지향 설계 원칙(SOLID) (0) | 2020.08.05 |
---|