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

Custom View 구현 시 프로토콜을 사용하면 좋은 이유 보통 커스텀 뷰를 구현하면 사용하는쪽에서 가져다 쓰는데, 사용하는곳이 여러곳이면 이 커스텀 뷰를 수정할때 여러곳을 고려해야하여 수정이 어려움이 존재 프로토콜을 사용한다면? 구현체의 의존성을 사용하는쪽에 두지 않는것이 가장 큰 의미, DIP(Dependency Inversion Principle) 사용하는쪽에서는 Interface에만 의존하고 있기 때문에 구현체에 여러가지 변화를 주더라도 유연한 구조 유지가 가능 ex) 커스텀 뷰가 공통 뷰이고 이 뷰가 Swift에서 SwiftUI로 넘어갈 때 역시도 protocol로만 외부에게 노출했으면 유연하게 수정이 가능 protocol로 커스텀 뷰 구현하기 커스텀 버튼을 만든다고 했을 때, UIView로 ..

Protocol 지향 프로그래밍이란? 특정 기능이 필요하여 기능을 구현하려고 할 때, protocol을 먼저 선언해 놓고 그 protocol을 준수하는 구현체를 생성하여 사용 기존 기능을 그대로 사용하면서 새로운 기능을 추가하려고 할 때, 상속보다는 protocol을 사용하여 확장하는 형태로 구현하는 것 Protocol 지향 프로그래밍을 해야하는 이유 DIP (Dependency Inversion Principle): 소스코드 의존성이 구현체에 의존하지 않고 추상(protocol)에 의존하는 것 DIP 구체적인 개념은 이전 포스팅 글 참고 기능제공(=확장성) 확장성이라는 의미는 개발자가 코드를 작성할 때 매우 자연스럽게 사용이 가능 사용하는쪽에서 매우 자연스러움 -> 프로토콜을 준수한다 -> 기능을 준수..

1. ReactorKit - 개념 2. ReactorKit - 테스트 방법 (Storyboard 사용, IBOutlet 테스트 방법) 3. ReactorKit - `TaskList 구현`, 템플릿 (template), 비동기 처리 transform(mutation:) 4. ReactorKit - `TaskEdit 구현`, 화면전환, 데이터 전달 ReactorKit 구현 방향 View, Reactor 생성 View의 storyboard에 UI 생성, IBOutlet 입력 Reactor의 Action 정의, Action에 해당하는 Mutation, State 정의 Reactor에서 필요한 service 정의 Reactor의 mutate, reduce 정의 ReactorKit 템플릿 구현 방법은 이곳 참고: ..

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

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..

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..

DIP 소스 코드 의존성이 추상에 의존하며 구현체에는 의존하지 않는 시스템 이유: 의존한다는 것은 의존하는 대상이 변경될때 영향을 받으므로, '추상'은 '구체'보다 변화가 적기때문에 '추상'에 의존함으로서 변경에 유연한 코드를 유지하기 위함 인터페이스는 구현체보다 변동성이 낮은 점을 사용 소프트웨어 설계자는 인터페이스의 변동을 낮추고 구현체에 기능을 추가할 수 있는 방법을 찾기위해 노력 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 DIP를 무시 예를 들어 자바의 String은 구체 클래스이며, String클래스가 변경되는 일이 거의 없으므로 DIP가 아니어도 안정적 Factory 아이디어: 변동성이 큰 구현체 객체를 생성할 때는 의존성을 주의하여 생성 builder 역할 구현체 객체를 사용하기..

Architecture vs SOLID Architecture는 빌딩, SOLID는 좋은 벽돌 SOLID를 통해서 좋은 아키텍처를 정의 SOLID: 함수와 데이터 구조를 클래스로 배치하고, 이 클래스들을 결합하는 방법에 대한 이론 cf) architecture vs design pattern vs SOLID architecture: 프로그램 내에서 큰 구조로 구성되어 다른 구성 요소들을 관리 방법으로 넓은 개념 design pattern: 특정 유형의 문제를 해결하는 방법으로 좁은 개념 SOLID: design pattern은 특정 문제 유형을 해결하는 개념이고, SOLID는 아키텍처를 위하여 세부 구조를 어떻게 배치하고 결합하는지에 관한 개념 SOLID의 목적 변경에 유연 이해하기 쉬움 많은 소프트웨어..