김종권의 iOS 앱 개발 알아가기

1. 유닛 테스트 방법 - Dependency Injection (@Injected) 주입 구조 Any]로 선언한 이유는 lazy하게 인스턴스들이 동작되도록 하기 위함 클로저의 특성 - 실행 지연이 가능 // https://medium.com/streamotion-tech-blog/magic-dependency-injection-in-swift-70476c7743ec public class DependencyStore { #if DEBUG public static var shared = DependencyStore() #else public static let shared = DependencyStore() #endif public init() {} /// A map of `identifier(for:)..

* 알아야하는 기본 지식 - 테스트 코드를 작성해야 하는 이유 - 클린 코드 (창발성) - DIP(Dependency Inversion Principle) 설계 전에 필요한 프레임워크 설치 RxSwift RxCocoa ViewModel을 testable되도록 만드는 이유 viewModel에는 UI 인풋에 따라 UseCase를 통해 비즈니스 로직을 실행 viewModel은 어떤값을 UI에 넘겨주어야하는지 정보를 담고 있는 컴포넌트 UI의 인풋부터 시작하여, 비즈니스 로직과 아웃풋까지 동시에 모두 테스트할 수 있는 컴포넌트는 ViewModel ViewModel을 testable하게 구현하는 아이디어 ex) LoginVM (로그인 ViewModel)을 만드는 예시 LoginVM 프로토콜을 만들어서 테스트할 때..

시스템을 만드는 것 도시를 만드는 것과 동일한 것이며, 도시를 세운다고 했을때 혼자서 도시를 만들기는 불가능하지만 각 수도 관리 팀, 전력 관리 팀, 교통 관리 팀들이 적절한 추상화와 모듈화에 의해서 효율적으로 돌아가는 방식 소프트웨어 팀도 시스템 수준에서도 깨끗함을 유지하는 방법이 중요 시스템 제작과 시스템 사용을 분리할 것 생성(Construction)과 사용(Use)의 차이 시스템 생성: 의존성을 연결하는 준비 과정 시스템 사용: 준비 과정 이후에 이어지는 런타임 로직 시스템 생성과 시스템 사용을 분리하는 대표적인 방법 - DI(Dependency Injection) 시스템 제작과 세스템 사용을 분리해야하는 근본적인 이유: "관심사"를 분리함으로서 SRP원칙을 준수하기 위함 1) 생성과 사용 분리 ..

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 구현체를 변경하는 일..

* 더욱 자세한 static framework외 dynamic framework 개념은 최신 포스팅 글 참고 프레임워크 vs 라이브러리 라이브러리 - "사용하는 주체"가 기능을 요청하며 사용 (언제 요청 할지, 언제 응답 받을지, 언제 결과 처리할 지 모두 주체가 결정) 프레임워크 - "사용하는 주체"와 기능의 제어권이 역전 IoC (Inversion of Control) RxSwift와 같이 bind 시켜놓으면 (제어권 부여), 이벤트 일어날 시 처리되는 (제어의 역전) 로직 Inversion of Control의 장점 재사용성 증가 관심사의 분리: As a Service (사람이 전기를 사용할 때 toggle switch만 키면 됨 - 관심사의 분리) DI(Dependency Injection)과의 ..