일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 리팩토링
- swift documentation
- 리펙토링
- swiftUI
- UITextView
- RxCocoa
- uitableview
- HIG
- UICollectionView
- 리펙터링
- clean architecture
- 스위프트
- Human interface guide
- tableView
- ribs
- Refactoring
- rxswift
- Protocol
- map
- uiscrollview
- ios
- collectionview
- Clean Code
- combine
- 애니메이션
- MVVM
- Observable
- SWIFT
- 클린 코드
- Xcode
- Today
- Total
목록clean architecture (24)
김종권의 iOS 앱 개발 알아가기
0. 코드로 알아보는 SOLID - 클래스 다이어그램 필수 표현 1. 코드로 알아보는 SOLID - SRP(Single Responsibility Principle) 단일 책임 원칙 2. 코드로 알아보는 SOLID - OCP(Open Close Principle) 개방 폐쇄 원칙 3. 코드로 알아보는 SOLID - LSP(Liskov Substitution Principle) 리스코프 치환 원칙 4. 코드로 알아보는 SOLID - ISP(Interface Segregation Principle) 인터페이스 분리 원칙 5. 코드로 알아보는 SOLID - DIP(Dependency Inversion Principle, testable) 의존성 역전 원칙 6. 코드로 알아보는 SOLID - Coordinato..
AppDelegate에서 첫 화면으로 AppDelegate는 앱 첫 시작화면으로 이동하는 AppFlowCoordinator를 소유 Coordinator를 통해 첫 시작화면으로 이동 Coordinator에서는 AppFlowDIContainer를 통해 이동하려는 화면에 해당하는 DIContainer 생성 > 이동하려는 화면의 Coordinator를 획득 > 이동하려는 화면의 coordinator에 정의되어 있는 start()함수를 통해 화면 전환 Coordinator 사용 방법 Coordinator를 사용하는 이유: ViewModel간 의존관계를 Coordinator로 끊은 상태 > ViewModel이 서로 의존하고 있지 않으므로 특정 ViewModel을 수정하면 Coordinator만 변경하면 되므로 상..
DTO DTO(Data Transfer Object): JSON의 response를 Entity로 변환 Data 하위에 존재 API로 부터 받은 response는 그대로 받고, response를 completion handler에서 domain 모델로 변환하는 식으로 사용 받은 response는 그대로 표출 > API의 response 모델을 알아보기 용이 사용하는 쪽에서 domain모델을 사용하도록 변환
Actor가 Entity를 받기까지 View는 ViewModel의 메소드를 호출 viewModel은 useCase 실행 > useCase는 Repository(DB or Network)에 데이터 요청 Repository에서 cache에 데이터가 있으면 바로 획득, 없으면 memory cache, disk cache로 기록 Respository로 부터 받은 데이터는 completion의 인수로 받을수 있어서 ViewModel이 이 데이터 획득 ViewModel은 자신의 Output 프로퍼티에 emit > 이 프로퍼티를 observe하고있던 View에서 Entity를 UI에 표출 예제 - Actor가 MovieList Entity를 요구 View는 ViewModel의 메소드를 호출 viewModel은 use..
의존관계 잘 변하는 것에서 변하지 않는것으로 의존관계가 되는게 이상적인 형태 잘 변하지 않는 계층인 Domain계층으로 Presentation과 Data 계층이 의존하는 형태 핵심: Actor가 Entity를 확인하는 flow View는 ViewModel의 메소드를 호출 viewModel은 useCase 실행 > useCase는 Repository(DB or Network)에 데이터 요청 Repository에서 cache에 데이터가 있으면 바로 획득, 없으면 memory cache, disk cache로 기록 Respository로 부터 받은 데이터는 completion의 인수로 받을수 있어서 ViewModel이 이 데이터 획득 ViewModel은 자신의 Output 프로퍼티에 emit > 이 프로퍼티를..
소스 코드의 의존성은 안쪽을 향하게끔 설계 안쪽으로 갈수록 잘 변하지 않는 요소들이기 때문 안쪽의 원은 바깥쪽의 원을 모르는 상태 바깥쪽의 원은 어떠한 것도 안쪽의 원에 영향을 주지 않는 구조 아키텍처 설계의 가정: 사용자(Actor)의 요구사항은 변경이 많이 없고 내부적으로 Web이나 DB, UI가 자주 바뀐다고 가정하여 설계 Entity Entity (=Enterprise Business Rules): Actor가 필요로 하는 데이터 모델을 의미 특정 '도메인'에서 사용되는 struct 모델 ex) Actor가 필요로하는 Movie와 MoviesPage에 관한 Entity struct Movie: Equatable, Identifiable { typealias Identifier = String en..
1. DI패턴 (필요한 곳에서 protocol에 선언하는 방법) 2. 테스트 구조를 고려한 DI패턴 Usecase Test를 위한 ViewModel 구조 ViewModel에 Input, Output이 존재하고 특정 Input일때 mock usecase를 동작시켜서 예상되는 Output이 나오는지 확인 ViewModel의 Input, Output 정의 protocol AInput { func viewDidLoad() } protocol AOutput { var calculatedValue: Observable { get } } protocol AViewModel: AInput, AOutput {} DefaultAViewModel 정의 final class DefaultAViewModel: AViewMode..
1. DI패턴 (필요한 곳에서 protocol에 선언하는 방법) 2. 테스트 구조를 고려한 DI패턴 DI 패턴 ADIContainer와 AViewModel이 있고 DIContainer에서 AViewModel를 만들 때, AViewModel에 필요한 값을 정의하는 방법 DIP와 테스트에 용이하기 위하여 protocol을 통해 설계는 2. 테스트 구조를 고려한 DI패턴 참고 1. DI패턴 (필요한 곳에서 protocol에 선언하는 방법)의 목적 DIContainer자체가 구현체가 되는 패턴 파악 DIContainer가 구현체가 되는 '패턴'에 대해서 보며, 이 방법은 의미없다는것을 알고 Usecase위치는 ViewModel에 있어야한다는 것을 깨닫는 목적 테스트시에 DIContainer 구현체를 변경하는 일..