B_log

Swift로 배우는 전략 패턴 (Strategy Pattern) – Head First 디자인 패턴 기반 설명

B_log — Wed, 9 Jul 2025 15:22:33 +0900

Swift로 배우는 전략 패턴 (Strategy Pattern) – Head First 디자인 패턴 기반 설명

『Head First Design Patterns』는 디자인 패턴을 쉽고 직관적으로 설명하는 명저입니다.

이번 글에서는 그중에서도 전략 패턴(Strategy Pattern)을 iOS 개발 환경에 맞게 Swift로 구현해보며 학습해보겠습니다.

전략 패턴이란?

전략 패턴(Strategy Pattern)은 알고리즘(또는 행위)을 객체로 캡슐화하여 상호 교환 가능하게 만드는 디자인 패턴입니다.

핵심 개념:

"행동을 클래스로 분리해서, 실행 중에 바꿀 수 있게 만든다."

✅ 전략 패턴 요약 정리

| 항목 | 내용 |

| ------ | ------ |

| 패턴명 | 전략(Strategy) 패턴 |

| 목적 | 알고리즘을 런타임에 자유롭게 교체 가능하게 만들기 |

| 특징 | 1개의 인터페이스 + 여러 전략 구현체 + Context 객체 |

| 장점 | OCP 만족, 중복 제거, 행동 교체 가능 |

| 자주 쓰이는 경우 | 로그인 방식, 정렬 기준, 렌더링 전략 등 |

책 속 예시: 오리 시뮬레이터

Head First 디자인 패턴에서 소개된 전략 패턴의 대표 예시는 오리 시뮬레이터입니다.

Duck 객체는 fly()와 quack() 같은 행동을 가짐
행동은 상황에 따라 달라지므로, 서브클래싱보다 구성(Composition)을 통해 캡슐화
FlyBehavior, QuackBehavior라는 인터페이스로 행동을 외부에서 주입

iOS에서의 실제 예: 로그인 전략

iOS 앱에서 다음과 같은 로그인 기능을 제공한다고 가정해봅시다:

Apple ID 로그인
Google 계정 로그인
게스트 로그인

이 3가지 로그인 방식은 서로 방식이 다르지만, "로그인"이라는 기능은 같기 때문에 전략 패턴이 유용합니다.

1. `LoginStrategy` 프로토콜 정의


protocol LoginStrategy {

    func login(completion: @escaping (Bool) -> Void)

}

2. 전략 클래스 구현


struct AppleLoginStrategy: LoginStrategy {

    func login(completion: @escaping (Bool) -> Void) {

        print("  Apple ID로 로그인 시도")

        // Apple 로그인 로직

        completion(true)

    }

}



struct GoogleLoginStrategy: LoginStrategy {

    func login(completion: @escaping (Bool) -> Void) {

        print("  Google 계정으로 로그인 시도")

        // Google 로그인 로직

        completion(true)

    }

}



struct GuestLoginStrategy: LoginStrategy {

    func login(completion: @escaping (Bool) -> Void) {

        print("  게스트 로그인")

        completion(true)

    }

}

3. Context 객체: `LoginManager`


final class LoginManager {

    private var strategy: LoginStrategy



    init(strategy: LoginStrategy) {

        self.strategy = strategy

    }



    func setStrategy(_ strategy: LoginStrategy) {

        self.strategy = strategy

    }



    func login(completion: @escaping (Bool) -> Void) {

        strategy.login(completion: completion)

    }

}

4. ViewController에서 사용


class LoginViewController: UIViewController {

    let loginManager = LoginManager(strategy: GuestLoginStrategy())



    @IBAction func appleLoginTapped() {

        loginManager.setStrategy(AppleLoginStrategy())

        loginManager.login { success in

            print("로그인 성공 여부: \(success)")

        }

    }



    @IBAction func googleLoginTapped() {

        loginManager.setStrategy(GoogleLoginStrategy())

        loginManager.login { success in

            print("로그인 성공 여부: \(success)")

        }

    }



    @IBAction func guestLoginTapped() {

        loginManager.setStrategy(GuestLoginStrategy())

        loginManager.login { success in

            print("로그인 성공 여부: \(success)")

        }

    }

}

iOS에서 자주 쓰이는 전략 패턴 예시

| 상황 | 전략이 필요한 이유 |

| ------ | ------------------- |

| 이미지 필터 처리 | 다양한 필터 적용 방식(흑백, 세피아 등)을 런타임에 변경 가능 |

| 정렬 기준 선택 | 리스트 정렬 기준을 이름순 / 날짜순 등으로 교체 |

| 광고 A/B 전략 | 유저 그룹별 광고 표시 전략 분리 |

| 데이터 저장 방식 | UserDefaults, Keychain, File 방식 전략적으로 교체 |

고급 팁: 클로저로도 전략을 표현할 수 있다

Swift에서는 꼭 클래스로만 전략을 구현하지 않아도 됩니다.

간단한 전략은 클로저로 대체할 수 있습니다.


typealias LoginClosure = (@escaping (Bool) -> Void) -> Void



let appleLogin: LoginClosure = { completion in

    print("  Apple로 로그인")

    completion(true)

}



let guestLogin: LoginClosure = { completion in

    print("  게스트로 로그인")

    completion(true)

}

이런 방식은 간단한 상황에서는 더욱 가볍게 전략을 구성할 수 있어 유용합니다.

결론

전략 패턴은 다음과 같은 경우에 아주 효과적입니다:

동작을 바꿔야 하지만, 코드를 수정하고 싶지 않을 때
여러 조건에 따라 다른 처리를 해야 할 때
테스트 가능성과 코드 확장성을 확보하고 싶을 때

Swift와 iOS 프로젝트에서 전략 패턴을 적극적으로 활용해보세요!

한층 더 유연하고 유지보수하기 쉬운 앱을 만들 수 있습니다.

참고

『Head First Design Patterns』, O’Reilly Media

Swift 공식 문서, Apple Developer Guide

React + Vite 프로젝트 시작하기

B_log — Sat, 17 May 2025 22:00:51 +0900

React + Vite 프로젝트 생성 방법

안녕하세요! 이번 글에서는 빠르고 가볍게 React 개발 환경을 구성할 수 있는 Vite를 사용해 프로젝트를 시작하는 방법을 소개합니다.
Vite는 빠른 번들링 속도와 간편한 설정으로 최근 가장 주목받는 프론트엔드 도구입니다.
React를 처음 시작하거나, CRA(Create React App)의 느린 속도에 지쳤다면 이 글을 꼭 따라해보세요.

✅ 1단계: Node.js 설치

Vite를 사용하려면 먼저 Node.js가 필요합니다.

공식 사이트: https://nodejs.org
LTS(Long Term Support) 버전 다운로드 권장

설치 후, 터미널에서 아래 명령어로 정상 설치 여부를 확인합니다.

node -v
npm -v

버전 정보가 잘 출력되면 다음 단계로 넘어가세요.

✅ 2단계: Vite + React 프로젝트 생성

Vite는 다양한 템플릿을 제공합니다. 우리는 React 템플릿을 선택해서 프로젝트를 생성할 것입니다.

npm create vite@latest my-app -- --template react

my-app은 원하는 폴더 이름으로 변경 가능합니다.
실행 후, 몇 가지 선택지가 나오면 기본 옵션(React + JavaScript)으로 진행해도 충분합니다.

✅ 3단계: 의존성 설치 및 개발 서버 실행

프로젝트 디렉토리로 이동한 후 필요한 패키지를 설치하고, 개발 서버를 실행합니다.

cd my-app
npm install
npm run dev

아래와 같은 주소가 터미널에 표시됩니다:

  ➜  Local:   http://localhost:5173/

브라우저에서 접속하면 Vite + React 초기 화면이 보이게 됩니다.

✅ 4단계: VSCode에서 프로젝트 열기 (선택 사항)

Visual Studio Code를 사용한다면 아래 명령어로 바로 프로젝트를 열 수 있습니다.

code .

단, code 명령어가 동작하지 않는다면 VSCode에서 Command Palette (Cmd+Shift+P 또는 Ctrl+Shift+P)를 열고
Shell Command: Install 'code' command in PATH 를 실행해주세요.

마무리

이제 React + Vite 기반의 개발 환경이 성공적으로 준비되었습니다!

이 환경에서는 빠른 HMR(Hot Module Replacement), 간단한 설정 파일, 빠른 빌드 속도 등 다양한 장점을 누릴 수 있어요.
앞으로 컴포넌트를 만들고, 상태 관리를 추가하며 프론트엔드 개발을 본격적으로 시작해보세요.

다음 글 예고

다음 포스팅에서는 Tailwind CSS를 Vite + React 프로젝트에 적용하는 방법을 알아볼 예정입니다.
궁금한 점이나 오류가 있다면 댓글로 남겨주세요. 감사합니다

Belkin 벨킨 썬더볼트 4 C 타입 초고속 케이블

B_log — Sun, 4 Aug 2024 15:00:47 +0900

구매처:

https://www.coupang.com/vp/products/6360212290?itemId=13424049638&vendorItemId=80678659372&q=%EB%B2%A8%ED%82%A8+%EC%84%A0%EB%8D%94%EB%B3%BC%ED%8A%B8&itemsCount=36&searchId=1037b23e4c3c4048a9c3dde10154c15d&rank=17&isAddedCart=

벨킨 썬더볼트 4 C타입 PD 100W 40Gbps 초고속 케이블 INZ003bt1MBK - 휴대폰/액세서리 | 쿠팡

현재 별점 4.9점, 리뷰 196개를 가진 벨킨 썬더볼트 4 C타입 PD 100W 40Gbps 초고속 케이블 INZ003bt1MBK! 지금 쿠팡에서 더 저렴하고 다양한 휴대폰/액세서리 제품들을 확인해보세요.

www.coupang.com

일반 C타입 케이블로 모니터 등을 연결하면 출력이 되지 않는 경우가 있습니다.

(특히 4K 모니터

)

이럴 때에는 데이터 케이블을 사용 해야하는데, 벨킨 썬더볼트 제품 구매 후기입니다.

케이블 박스는 아래와 같이 패키징 되어있습니다.

뒷면은 아래와 같습니다.

구성품은 굉장히 단순합니다.

데이터 케이블 스펙은 아래와 같습니다.

• 고속 데이터 전송: 최대 40Gbps의 속도로 데이터를 전송할 수 있어 대용량 파일 전송에 적합합니다.

• 고해상도 디스플레이 지원: 4K 및 5K 해상도의 디스플레이를 지원합니다.

• 전력 공급: 최대 100W의 전력 공급이 가능하여 빠른 충전이 가능합니다.

• 길이: 다양한 길이 옵션이 있어 필요에 맞게 선택할 수 있습니다.

• 내구성: 벨킨의 높은 품질과 내구성을 자랑합니다.

터틀비치 리콘(Turtle Beach Recon) Xbox 컨트롤러 개봉기 및 리뷰

B_log — Sat, 20 Jul 2024 17:59:32 +0900

구매 방법 및 가격

인터파크에서 터틀비치 통합전이 열려 저렴한 가격에 리콘 컨트롤러를 구매했습니다.

구매 당시 가격은 제품 약 39,000원, 배송비 포함 약 42,000원 에 구매했습니다.

박스 외관

먼저, 터틀비치 리콘 컨트롤러의 박스 외관입니다. 깔끔한 디자인과 함께 제품의 주요 기능들이 박스 전면에 잘 설명되어 있습니다.

박스 열었을 때

박스를 열면, 컨트롤러와 함께 안전하게 포장된 구성품들을 확인할 수 있습니다. 포장이 매우 견고하고 깔끔하게 되어 있습니다.

컨트롤러

이제 컨트롤러를 살펴보겠습니다. 디자인은 매우 인체공학적으로 되어 있으며, 손에 잡히는 느낌이 아주 좋습니다.

구성품

구성품으로는 컨트롤러 본체 외에도 USB 케이블, 사용 설명서 등이 포함되어 있습니다. 필요한 모든 것이 잘 갖추어져 있습니다.

터틀비치 리콘 컨트롤러의 장단점

장점

터틀비치 리콘 컨트롤러는 인체공학적인 디자인 덕분에 장시간 사용해도 손목이나 손에 무리가 가지 않습니다.

또한 터틀비치의 독자적인 사운드 조절 기능이 내장되어 있어, 게임 도중에도 쉽게 음향을 조절할 수 있다는 점이 큰 장점입니다.

특히, 고음질의 사운드를 제공해 게임 몰입도를 높여줍니다.

또한, 컨트롤러의 내구성도 뛰어나 오랜 시간 사용해도 문제없이 사용할 수 있습니다.

추가로 매핑 가능한 커스텀 키도 2개 있습니다.

단점

그러나 몇 가지 단점도 있습니다.

우선, 컨트롤러의 무게가 다소 무겁게 느껴질 수 있습니다. 장시간 사용 시 손목에 부담을 줄 수 있습니다.

또한 무선이 아닌 유선 컨트롤러 입니다.

그러나 이러한 단점에도 불구하고, 전체적인 성능과 기능은 충분히 그 가치를 하고 있다고 생각합니다.

데이터 저장: Core Data vs. Realm

B_log — Sat, 9 Sep 2023 16:31:02 +0900

개요

SwiftUI를 활용해 앱을 개발하면서, 데이터 저장 도구에 대한 선택지를 고민했습니다.

iOS 앱을 개발할 때 데이터 저장 솔루션을 선택하는 것은 중요한 결정입니다.

데이터를 어떻게 저장하고 관리할지를 결정하는 것은 앱의 성능, 확장성 및 개발 경험에 큰 영향을 미칩니다.

이 글에서는 Core Data와 Realm의 장단점을 비교하고 어떤 상황에서 어떤 것을 선택해야 하는지 알아보겠습니다.

Core Data

장점:

공식적인 Apple 지원: Core Data는 Apple에서 제공하는 공식 데이터 저장 및 관리 프레임워크로서 iOS 개발 생태계와 밀접한 통합을 제공합니다. SwiftUI와의 호환성이 뛰어나며, Apple의 업데이트에 즉시 대응할 수 있습니다.

간편한 통합: SwiftUI에서 @FetchRequest를 사용하면 데이터를 가져오고 SwiftUI 뷰와 쉽게 바인딩할 수 있습니다. 이는 간단한 데이터 바인딩과 데이터 변경 감지를 위한 편리한 방법을 제공합니다.

복잡한 데이터 모델 처리: Core Data는 복잡한 데이터 모델과 관계를 다루기에 적합하며, 객체 그래프와 관계를 쉽게 설정하고 관리할 수 있습니다.

단점:

러닝 커브: Core Data는 초기 설정과 개념 이해에 시간이 걸릴 수 있으며, 초보자에게는 조금 복잡할 수 있습니다.

성능 문제: 대량의 데이터를 다루는 경우 성능 문제가 발생할 수 있으며, 신중한 최적화가 필요할 수 있습니다.

Realm

Realm: https://github.com/realm/realm-swift

장점:
빠른 성능: Realm은 객체 그래프를 직접 다루므로 작업이 빠르며 효율적입니다. 대량의 데이터 처리 및 복잡한 쿼리에 강력합니다.

간단한 API: Realm은 간단한 API를 제공하여 데이터를 쉽게 저장하고 검색할 수 있습니다. SwiftUI와 함께 사용하기 특히 편리합니다.

다중 플랫폼 호환성: Realm은 iOS 뿐만 아니라 Android, React Native 등 다양한 플랫폼에서 사용할 수 있어 다중 플랫폼 프로젝트에 이상적입니다.

단점:

비공식 솔루션: Realm은 Apple에서 제공하는 공식 프레임워크가 아니므로, Apple의 업데이트와 호환성을 유지하는 데 약간의 노력이 필요할 수 있습니다.

상대적으로 작은 커뮤니티: Core Data에 비해 상대적으로 작은 커뮤니티를 가지고 있으므로 문제 해결과 지원을 찾는 것이 어려울 수 있습니다.

결론

SwiftUI와 함께 데이터를 저장하기 위해 Core Data와 Realm은 각각 장점과 단점을 가지고 있습니다. Core Data는 Apple의 지원과 통합성을 강조하며 복잡한 데이터 모델을 다루기에 적합합니다. 반면, Realm은 빠른 성능과 간단한 API로 대량의 데이터 처리에 적합하며 다중 플랫폼 호환성을 제공합니다.

두 프레임워크 모두 강력하며 SwiftUI와 함께 원활하게 통합될 수 있습니다.

[헤드퍼스트 디자인패턴 with Swift] - 2.옵저버 패턴(Observer Pattern)

B_log — Sun, 19 Mar 2023 17:25:10 +0900

☀️ 기상 모니터링 애플리케이션 만들기

현재 기상 조건(온도, 습도, 기압)을 추적해서 아래 결과를 표시하는 앱을 만들어 보려고 해요 :]

1. 현재 조건
2. 기상 통계
3. 간단한 기상 예보

기상 모니터링이므로 당연히 이 항목들은 모두 실시간으로 갱신돼야 해요.

여기에 더해 추가 요구 사항이 있어요..

다른 개발자가 직접 날씨 디스플레이를 만들어서 바로 넣을 수 있도록 확장 가능해야 합니다.
나중에 새로운 디스플레이를 손쉽게 추가할 수 있도록 해주세요.

시스템 파악하기

이 시스템은 총 3가지로 구성되어 있어요.

1. 기상 스테이션

➡️ 실제 기상 정보를 수집하는 물리 장비(데이터를 제공하는 부분)

2. 기상 스테이션으로부터 오는 정보를 추적하는 객체

➡️ WeatherData 객체

3. (제공되는 데이터를 볼 수 있는) 디스플레이 장비

➡️ 원하는 조건을 선택해서 표시 가능

쉽게 생각하면 서버에서 오는 정보를 View로 띄워주는 것처럼

기상 스테이션 ➡️ 데이터 가공 ➡️ 디스플레이 장비

의 순서로 동작이 이루어져요.
그래서 직접 구현해야하는 부분은 아래 2가지입니다.

1. Weather Data를 받아 통합하여 재가공

2. 디스플레이로 1의 결과 보여주기(옵션 선택 가능)

WeatherData 클래스 살펴보기

먼저 객체를 살펴볼게요.

Swift에서는 get으로 시작하는 메서드 네이밍을 지양하지만, 책에서 Java를 베이스로 하고 있기 때문에 이름을 그대로 가져왔어요.

이제 해야 할 작업은 기상 관측값이 갱신될 때마다 호출될 메서드 measurementsChanged()를 구현하면 돼요.

‍♂️ measurementsChanged 구현하기

이 메서드는 결국 새로 가져온 정보를 기준으로 디스플레이를 업데이트하는 작업을 해야 해요.

구현 목표를 조금 더 정리해 볼게요!

1. measurementsChanged() 메서드가 어떤 식으로 호출되는지 알 필요는 없음(호출된다는 사실만 앎)
2. measurementsChanged()에서 디스플레이를 업데이트

+ 추가될 디스플레이를 대비해 확장성 있게 만들기

이것을 바탕으로 코드를 추가해 볼게요!

이름에서 유추할 수 있듯이 각 메서드는 우리가 출력해야 될 View의 결과물들을 업데이트하는 역할을 해요.

1. 현재 조건 업데이트 ➡️ currentConditionsDisplay.update
2. 기상 통계 업데이트 ➡️ statisticsDisplay.update
3. 간단한 기상 예보 업데이트 ➡️ forecastDisplay.update

즉, 디스플레이를 갱신해요.

여기서 문제는 무엇일까요?

현재 구현 문제 이해하기

1. 화면을 update해주는 메서드들을 각 Display 객체가 가지고 있고, 이 객체들은 구체적인 구상체예요.

그래서 이 클래스는 다른 구상체에 맞춰서 코딩했기 때문에(의존) 수정이 생길 경우 이 부분에 반드시 수정이 필요해요.

➡️ 캡슐화 필요

2. 세 종류의 디스플레이가 모두 update 메서드를 가지며 같은 parameter들을 입력받고 있어요.

3. 실행 중에 디스플레이를 더하거나 빼기가 어려운 구조예요.

옵저버 패턴 사용하기

사실 iOS 개발자들은 Notification Center의 존재 때문에 Observer Pattern에 익숙한 것 같아요.

위의 구현을 옵저버 패턴을 사용해서 구현해 볼게요.

여기서 용어 정리가 필요한데,

관찰할 데이터 ➡️ Subject(주제)
이 데이터를 관찰할 관찰자 ➡️ Observer

라고 해요.

즉, 옵저버 객체들은 대상 주제를 구독하고 있으며 주제 데이터가 바뀌면 갱신 내용을 전달받아요.

(저는 주제라는 말보다는 관찰 대상이라는 말이 조금 더 와닿네요)

옵저버 패턴의 정의

옵저버 패턴은 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(1:N) 의존성을 정의합니다.

여기서 1은 당연히 Subject, N은 Observer가 될 거예요.

1 : N의 의미는 결국 하나의 Subject를 여러 Observer들이 동시에 관찰할 수 있다는 의미예요.

옵저버 패턴에서는 주제가 상태를 저장하고 제어해요.

그래서 상태가 들어있는 객체는 하나만 있을 수 있어요.

반면에 옵저버는 상태를 사용하지만 (반드시) 소유할 필요는 없어요(관찰한 결과물을 활용하면 되니까).

그래서 옵저버는 하나의 주제에 대해 여러 개가 있을 수 있으며, 주제에서 상태가 바뀌었다는 사실을 알려 주길 기다리는 주제에 의존적인 성질을 가져요.

옵저버 패턴은 여러 방법으로 구현할 수 있는데, 보통은 주제 인터페이스와 옵저버 인터페이스가 들어있는 클래스 디자인으로 구현해요.

Subject(관찰 대상)

Observer(옵저버)

느슨한 결합(Loose Coupling)

느슨한 결합은 객체들이 상호작용할 수 있지만, 서로를 잘 모르는 관계를 의미해요.

이렇게 객체들의 관계를 느슨하게 설계하면, 유연한 구조를 만들 수 있어요.

옵저버 패턴은 느슨한 결합의 대표적인 예예요!

1. 주제는 옵저버가 특정 인터페이스(Swift에서 프로토콜)를 구현한다는 사실만 알아요

주제가 옵저버의 구상 클래스가 무엇인지, 옵저버가 무엇을 하는지 알 필요가 없어요.

2. 옵저버는 아무 때나 새로 추가하거나 제거할 수 있어요

주제는 Observer 인터페이스를 구현하는 객체의 목록에만 의존하기 때문에 이 목록을 변경함으로써 언제든지 새로운 옵저버를 추가하거나 기존 옵저버를 제거할 수 있어요.

3. 새로운 형식의 옵저버를 추가할 때도 주제를 변경할 필요가 없어요

새로운 구상 클래스가 생겼다고 해도 기존의 주제는 변경이 필요하지 않아요.

새로운 클래스에서 Observer 인터페이스(프로토콜)를 구현하고, 옵저버로 등록하기만 하면 돼요.

주제는 신경 쓸 필요가 없어요.

4. 주제와 옵저버는 서로 독립적으로 재사용할 수 있어요

5. 주제나 옵저버가 달라져도 서로에게 영향을 미치지 않아요

디자인 원칙: 상호작용하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다.

기상 스테이션 구현하기

위에서 설명한 구조를 Observer 패턴에 맞게 다시 구성해 볼게요.

책에서는 우선 update시에 측정치를 직접 전달하는 게 상태를 갱신하는 가장 간단한 방법이라고 생각했어요.

Subject 프로토콜 구현하기

디스플레이 요소 구현하기

이 구현 중 update 메서드 내에서 display 하는 부분이 상당히 마음에 걸렸어요...

마침 책에서도 그 이야기를 다루고, 추후 다른 챕터에서 다룬다고 이야기해요!

☁️ Weather Station 만들기

☕️ Cocoa의 Key-Value Observing을 통해 실제 옵저버 패턴 예시 보기

책에서는 이러한 옵저버 패턴의 예시 중 하나로 Cocoa를 이야기해요.

실제로는 어떻게 옵저버 패턴이 적용되는지 살펴볼게요!

https://developer.apple.com/documentation/swift/using-key-value-observing-in-swift

Using Key-Value Observing in Swift | Apple Developer Documentation

Notify objects about changes to the properties of other objects.

developer.apple.com

여기서 말하는 MyObjectToObserve는 책에서 이야기하는 Subject에요.
(이해하기 쉬운 네이밍이군요..)

책의 예시와 마찬가지로 시간을 업데이트하는 로직이 정의되어 있어요.

MyObserver는 당연히 옵저빙 하는 객체예요.

마찬가지로 관찰 대상(subject)을 저장하고, 그 정보를 기반으로 observation이라는 프로퍼티를 저장해요.

메서드를 보면 저장 후에 결과를 print해주는 부분이 completion handler로 정의되어 있는 것 같아요.

마찬가지로 아래와 같이 정의해 주고

아래와 같이 사용하면 돼요!

디자인 원칙: 상속보다는 구성(composition)을 사용한다

상속 ➡️ is-a 관계

구성 ➡️ has- a 관계

구성은 중복되는 로직들을 갖는 객체를 분리 구현하고, 이 객체를 주입받아 중복 로직을 호출함으로써 프로토콜을 재사용하는 방법이에요.

상속은 중복 코드를 제거하는 좋은 방식이지만 결합도가 높아지고 유연성이 떨어지며, 다중 상속의 문제 등을 유발할 수 있어요.

그래서 중복 코드를 제거해야 할 때에는 구성을 활용하는 것이 더 좋아 보여요!

2장은 여기까지입니다 :]

정리하면, 옵저버 패턴은 관찰자와 관찰 대상을 나누어 구현하고, 1:N의 관계에서 관찰 대상에 변화가 생겼을 때 일괄적으로 관찰자에게 해당 변경을 적용하는 패턴이에요.

결국 책임을 분리해서 결합도를 낮추고, "변화의 trigger ➡️ 변화를 만드는 객체"의 구조라고 이해했어요.

[헤드퍼스트 디자인패턴 with Swift] - 1. 전략 패턴(Strategy Pattern)

B_log — Sun, 12 Mar 2023 19:33:19 +0900

헤드퍼스트 디자인패턴 시작하기

"헤드퍼스트 디자인패턴"은 Java를 기반으로 쓰인 책이지만, 여기서는 Swift로 구현하며 내용을 정리해 볼게요!
항상 그렇지만 이 글은 개인적인 정리의 목적으로 작성하는 것이기 때문에 책을 직접 읽어보기를 추천드려요 :]

오리 시뮬레이션 게임 만들기

SimUDuck이라는 오리 게임을 만들어볼게요 :]

방법 1. 일반적인 상속 구조 사용하기

일반적인 표준 객체지향 기법을 사용하여 Duck이라는 Super class를 만들고, 상속을 통해 여러 오리를 만들어요.

(private, final 등 세세한 설정 등은 생략할게요)

각 오리들은 부모 클래스(Duck)의 메서드를 override 하여 사용해요.

추가 요구 사항 발생

➡️ 오리는 날 수 있어야 합니다

여기서 Duck 클래스에 fly 메서드를 추가해요.

이렇게 되면 모든 오리에 하늘을 나는 기능이 추가돼요.

문제는 오리 중에 장난감 오리처럼 하늘을 날 수 없는 오리가 있다는 거예요

이 문제를 단편적으로 해결하기 위해서는 날지 못하는 오리에서 fly를 override 하여 아무 동작도 하지 않게 만들 수 있어요.

하지만 여기서 다른 문제가 발생해요.

추가 요구 사항 발생

➡️ 앞으로 6개월마다 제품을 업데이트하기로 결정

이렇게 상속을 사용하는 상황에서 제품 스펙이 지속적으로 업데이트된다면 유지 보수에 큰 리소스가 들어가요.

모든 Duck의 메서드들을 전부 살펴보면서 상황에 따라 변경해야 해요.

방법 2. 프로토콜(인터페이스) 사용하기

위의 방법 1에서 구현한 fly() 메서드를 Duck 클래스에서 빼고 Flyable이라는 Protocol을 만들어서 채택하는 구조로 만들어요.

이렇게 하면 같은 Duck이라고 하더라도 "하늘을 나는 능력을 가진 오리"만 이 프로토콜을 채택시켜서 문제를 해결할 수 있어요.

책에서 말하는 이 방법의 단점

(자바 기준으로) 이렇게 구현하면 코드 중복이 많이 발생해요.
fly의 기능이 대부분 오리에서 같다고 했을 때, Flyable을 채택하는 오리들에서 같은 코드가 불필요하게 반복되어야 해요.

날아가는 동작을 조금 바꾸기 위해 Duck의 서브클래스에서 fly 메서드들을 전부 수정해야 할 수도 있다는 단점이 있어요.

➡️ Swift에서는 사실 Protocol의 extension에서 func을 정의하는 기능이 있기 때문에 이 문제에서 벗어날 수 있어요.
Java와 다르게 POP의 관점에서 코드를 구현할 수 있기 때문에 책에서 말하는 단점은 Swift에 적용되지 않는다고 생각해요.

디자인 원칙: 애플리케이션에서 달라지는 부분을 찾아내고, 달라지는 부분과 분리한다

달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 '캡슐화'해요.

그러면 코드를 변경하는 과정에서 의도치 않게 발생하는 일을 줄이면서 시스템의 유연성을 향상시킬 수 있어요.

이 원칙을 적용하는데 많은 시간을 쏟아야 해요.

바뀌는 부분은 따로 뽑아서 캡슐화한다. 그러면 나중에 바뀌지 않는 부분에는 영향을 미치지 않고 그 부분만 고치거나 확장할 수 있다

이 개념은 다른 모든 디자인 패턴의 기반을 이루는 원칙이에요.

이것을 기반으로 위의 오리 문제를 다시 살펴볼게요.

Duck 클래스를 '변화하는 부분과 그대로 있는 부분'으로 분리하려면, 2개의 클래스 집합을 만들어야 해요.

하나는 하늘을 나는 것과 관련된 것, 다른 하나는 꽥꽥 거리는 것과 관련된 부분이에요.
각 클래스 집합에는 각각의 행동을 구현한 것을 전부 집어넣어요.
예를 들어, 꽥꽥거리는 행동을 구현하는 클래스, 삑삑거리는 행동을 구현하는 클래스, 그리고 아무 소리도 내지 않는 행동을 구현하는 클래스를 만들어요.

fly()와 quack()은 오리 종류에 따라 달라져요.

그래서 Duck 클래스로부터 이 두 메서드를 분리하려면 2개의 메서드 모두 Duck 클래스에서 끄집어내서 각 행동을 나타낼 클래스 집합을 새로 만들어야 해요.

그러면 이 행동들을 구현하는 클래스 집합은 어떻게 디자인해야 할까요?

최대한 유연하게 만드는 것이 좋아요!
애초에 이러한 문제가 발생했던 이유가 이 부분에서 변경점이 생길 가능성이 높아서였으니까요.

디자인 원칙: 구현보다는 인터페이스 맞춰서 프로그래밍한다.

각 행동은 인터페이스로 표현하고, 이런 인터페이스를 사용해서 행동을 구현해요.

이제 Duck 클래스에서 나는 행동과 꽥꽥거리는 행동을 구현하지 않아요.

행동(Behavior) 인터페이스는 Duck 클래스가 아니라 행동 클래스에서 구현해요.

"인터페이스에 맞춰서 프로그래밍한다"라는 말은 사실 "상위 형식에 맞춰서 프로그래밍한다"라는 말입니다.

여기서 말하는 인터페이스는 중의적으로 사용되었는데, 자바에서 말하는 인터페이스를 의미하기도 하고 인터페이스라는 개념을 지칭하기도 해요. 반드시 자바의 인터페이스(Swift의 프로토콜)를 사용하라는 뜻은 아니에요.

핵심은 실제 실행 시에 쓰이는 객체가 코드에 고정되지 않도록 상위 형식에 맞춰 프로그래밍해서 다형성을 활용해야 한다는 것이에요.

또한 여기서 "상위 형식에 맞춰서 프로그래밍하라"는 "변수를 선언할 때 보통 추상 클래스나 인터페이스 같은 상위 형식으로 선언해야 한다"라는 의미예요. 객체를 변수에 대입할 때 상위 형식을 구체적으로 구현한 형식이라면 어떤 객체든 넣을 수 있는 유연성이 생기기 때문이에요. "그러면 변수를 선언하는 클래스에서 실제 객체의 형식을 몰라도 된다"는 의미로도 해석될 수 있어요.

이렇게 구현한 결과물은 아래와 같아요.

이렇게 디자인하면 다른 형식의 객체(오리가 아닌 다른 객체)에서도 나는 행동과 꽥꽥 거리는 행동을 재사용할 수 있어요.

이 행동 자체가 오리 안에 숨겨져있지 않으니까요!

그리고 Duck 클래스를 건드리지 않고도 새로운 행동을 추가할 수 있어요.

상속을 쓸 때 떠안게 되는 부담을 떨쳐 버리고 재사용의 장점을 가져갈 수 있어요 :]

Q. 행동만 나타내는 클래스는 어색해요. 클래스는 원래 어떤 대상을 나타내는 것 아닌가요? 상태, 행동을 모두 포함해야 하는 것 아닌가요?

객체지향 시스템에서는 질문한 내용이 맞습니다. 하지만 "행동"도 상태와 메서드를 가질 수 있어요! (최고 높이, 속도 등)

객체라는 개념이 반드시 어떤 하나의 물체로 한정될 필요는 없어요.

그럼 위의 프로토콜을 가지고 Duck을 다시 구현해 볼게요!

동적으로 오리의 행동 지정하기

앞서서 특정 구현에 맞춰서 프로그래밍하면 안 된다고 했어요.

현재는 앞에 있는 생성자를 보면 Quack라는 구상 클래스의 인스턴스로 선언되어 있기 때문에 Duck이 Quack의 구현에 맞춰져 있어요.

위에서는 프로퍼티의 생성 시점에 동작이 확정되지만, 이 부분을 유연하게 만들 수 있어요.

아래와 같이 메서드를 추가하면 코드 진행 중에 동작의 변경이 가능해요.

두 클래스의 관계

"A에는 B가 있다"의 관계를 생각해 보면, 오리에는 FlyBehavior, QuackBehavior가 있어요.

각각 나는 행동과 꽥꽥 거리는 행동을 위임해요.

이런 식으로 "두 클래스를 합치는 것을 구성(composition)을 이용한다"라고 해요.

디자인 원칙: 상속보다는 구성을 활용한다.

Composition을 활용하면 시스템의 유연성을 향상시킬 수 있어요.

iOS에서 전략 패턴 구현해보기

protocol Theme {
    var backgroundColor: UIColor { get }
    var textColor: UIColor { get }
    // 추가적인 테마 관련 프로퍼티 및 메서드 정의
}

struct LightTheme: Theme {
    var backgroundColor: UIColor = .white
    var textColor: UIColor = .black
    // 추가적인 테마 관련 프로퍼티 및 메서드 구현
}

struct DarkTheme: Theme {
    var backgroundColor: UIColor = .black
    var textColor: UIColor = .white
    // 추가적인 테마 관련 프로퍼티 및 메서드 구현
}

class ViewController: UIViewController {
    var theme: Theme
    
    init(theme: Theme) {
        self.theme = theme
        super.init(nibName: nil, bundle: nil)
    }
    
    // 뷰 컨트롤러의 테마 관련 로직을 구현
    // 예: 배경색 설정, 텍스트 색상 설정 등
}

위의 예시에서 Theme 프로토콜은 테마 관련 속성을 정의하고 있어요.
그리고 LightTheme과 DarkTheme은 각각 테마 프로토콜을 구현한 전략 클래스에요.

이렇게 구현된 전략 패턴을 통해 애플리케이션의 테마를 동적으로 변경할 수 있어요.

정리

전략 패턴(Strategy Pattern)은 알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해 줘요.
전략 패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적인 변경(관리)이 가능해요!

[iOS] - Xcode 단축키 정리

B_log — Sat, 14 Jan 2023 20:39:25 +0900

개요

자주 쓰는 단축키는 초록색 으로 표시하고, 개인적으로 잘 외워지지 않는 단축키는 핑크색 으로 표시했어요(나중에 보려고 정리한 거라..)

참고의 Apple 공식 문서에 들어가면 더 많은 단축키를 볼 수 있어요!

필요에 따라 지속적으로 업데이트될 예정이에요.

아래 정보는 Xcode 14.1을 기준으로 해요.

혹시 잘못된 정보가 있다면 피드백 부탁드려요

XCode 단축키

Command(⌘) + Shift(⇧) + K : 프로젝트 클린
Command(⌘) + B : 프로젝트 빌드
Command(⌘) + R : 프로젝트 실행
Command(⌘) + I : 프로젝트 프로파일링 빌드
Command(⌘) + T : 새로운 탭 열기
Command(⌘) + [ : 해당 코드 왼쪽으로 indent 한 탭(4 spaces or 2 spaces) 이동
Command(⌘) + . : 실행 중인 앱 강제 종료
Command(⌘) + , : XCode 프로퍼티창 열기
Command(⌘) + Shift(⇧) + O : 프로젝트 내 파일 / 클래스 / 함수 검색
Command(⌘) + Shift(⇧) + F : 파인드 창으로 캐럿 강제 이동
Command(⌘) + Shift(⇧) + 숫자 0 : 해당 코드 관련 Document 창 열기
Command(⌘) + F : 현재 창 검색
Command(⌘) + Shift(⇧) + J : 현재 보고 있는 파일 위치 확인
Command(⌘) + G : 현재 페이지에서 텍스트 에디트에 적힌 문구 순차 검색
Command(⌘) + Shift(⇧) + G : 현재 페이지에서 텍스트 에디트에 적힌 문구 역순차 검색
Command(⌘) + Option(⌥) + ,(Comma) : 현재창 이중 분할
Command(⌘) + Option(⌥) + n : 새로운 폴더 생성
Command(⌘) + Enter : 현재창을 단일창으로 변경
Command(⌘) + / : 해당라인 주석 걸기 ( 다중 라인도 가능 )
Control(⌃) + Command(⌘) + 좌우 화살표 : 이전/이후 페이지 이동
Control(⌃) + I : 선택된 구간 정해진 설정으로 들여쓰기(Indentation)
Control(⌃) + Shift(⇧) + Click: 멀티 커서
Command(⌘) + D : 줄 복사

Xcode 네비게이터(Navigator) 영역

영역 : 프로젝트(1), 소스 Control(2), 심벌(3), 검색(4), 이슈(5), 테스트(6), 디버그(7), 브레이크 포인트(8), 리포트(9)
Command(⌘) + 0 : 왼쪽에 네비게이터 영역 윈도우 숨기기 & 열기
Command(⌘) + 1 : 프로젝트 파인더 열기
Command(⌘) + 2 : 프로젝트 Hierarchy(계층도) 창 열기
Command(⌘) + 3 : 프로젝트 검색 창 열기
Command(⌘) + 4 : 프로젝트 warning 및 error 창 열기
Command(⌘) + 6 : 테스트 타깃창 열기
Command(⌘) + 7 : 디버그 세션 창 열기
Command(⌘) + 8 : 모든 브레이크 포인트를 보여주는 창 열기(설정 및 해제 가능)
Command(⌘) + 9 : 프로젝트 리포트 창 열기

인스펙터(Inspector) 영역

Command(⌘) + Option(⌥) + 0(숫자키) : 인스펙터(inspector) 영역 열기/닫기
Command(⌘) + Option(⌥) + 1~3(숫자키) : 인스펙터(inspector) 영역 내 이동

디버깅 관련

Command(⌘) + \ : 브레이크 포인트 걸기
Command(⌘) + Y : 브레이크 포인트 비활성화 / 활성화
Command(⌘) + Shift(⇧) + Y : 하단 디버그 세션 창 열기 / 닫기
Command(⌘) + U: Unit Test 실행
F6 : 다음 라인 ( Step Over )
F7 : 현재 라인 내부 진입 ( Step Into )
F8 : 현재 함수에서 나가기 ( Step Out )
Command(⌘) + Shift(⇧) + Y : 실행 중 멈춤 ( Pause ) & 멈춤 상태에서 재 진행

Source Control 관련

Command(⌘) + Shift(⇧) + C : 커밋창 열기
Command(⌘) + Shift(⇧) + X : 업데이트하기

iOS Simulator

Command(⌘) + S : 현재 시뮬레이터에 뜬 화면 캡처

기본적인 맥 단축키

Command(⌘) + A : 전체 선택
Command(⌘) + Z : 되돌리기
Command(⌘) + X : 자르기
Command(⌘) + C : 복사
Command(⌘) + V : 붙여 넣기
Command(⌘) + BackSpace : 해당 라인 지우기
Command(⌘) + 방향키 : 해당 방향의 끝으로 이동
Command(⌘) + Up: 해당 창 가장 위로(Home 키도 동일하게 작동)
Command(⌘) + Down : 해당 창 가장 아래로(End 키도 동일하게 작동)
Command(⌘) + Left : 선택된 텍스트라인 가장 왼쪽으로
Command(⌘) + Right : 선택된 텍스트라인 가장 오른쪽으로
Control(⌃) + 좌/우 : 페이지 변경
Command(⌘) + Shift(⇧) + 3 : 선택한 화면 영역 이미지 파일로 캡처
Command(⌘) + Shift(⇧) + 4 : 선택한 화면 영역 클립보드 캡처
Command(⌘) + Space : Spotlight 검색
Command(⌘) + W : 현재 창 닫기
Command(⌘) + Q : 선택된 프로그램 종료
Command(⌘) + H : 현재 창 숨기기
Control(⌃) + Space : 언어 변환

참고

https://developer.apple.com/library/archive/documentation/IDEs/Conceptual/xcode_help-command_shortcuts/MenuCommands/MenuCommands014.html

[iOS] 앱 테스트를 위해 네트워크 속도 조절하기(Mac & iPhone)

B_log — Thu, 6 Oct 2022 21:49:09 +0900

개요

앱의 크래쉬를 분석하다 보면 네트워크 이슈를 의심하는 경우가 있어요.

그런 상황을 재현하기 위해 맥에서 네트워크 속도를 조절할 수 있는 툴을 소개합니다 :)

Mac에서 네트워크 속도 조절하기

Network Link Conditioner는 애플에서 공식적으로 제공해주는 도구예요.

그래서 안심하고 사용할 수 있어요.

설치하기

2022년 10월 기준 Network Link Conditioner는 Apple Developer 사이트에서 다운로드할 수 있어요.

Apple Developer Downloads

로그인 - Apple

idmsa.apple.com

Additional Tools 혹은 Network Link Conditioner로 검색하면 아래와 같이 나와요.

Network Link Conditioner를 직접 받는 게 아니라 Additional Tools를 받아서 그 안에 있는 Network Link Conditioner를 사용할 수 있어요.

현재 본인의 Xcode 버전에 맞는 툴을 받아 dmg 파일을 실행시키면 아래와 같이 폴더가 구분돼요.

그 안에 .prePane 파일이 있어요.

실행시킵니다!

모든 사용자를 위해 설치할거냐고 물어보는데 OK를 하면

맥의 시스템 환경설정에서 하나가 추가됩니다!

사용하기

설명이 필요하지 않을 정도로 간단합니다!

Profile에서 원하는 네트워크 환경을 설정해주고

OFF를 ON으로 켜주면

테스트 환경이 완성됩니다!

iPhone에서 네트워크 속도 조절하기

iPhone은 추가적인 설치 없이도 손쉽게 네트워크 테스트를 할 수 있어요!

설정 > 개발자 모드

에 들어가면 Network Link Conditioner가 있어요.

들어가 보면

똑같이 속도 조절이 가능합니다!

[iOS] - XCTest 놓치고 있던 내용 가벼운 정리

B_log — Mon, 12 Sep 2022 15:44:48 +0900

ref: https://www.agnosticdev.com/blog-entry/swift/swift-network-testing-automate-xctest-python

개요

이번 글은 공유의 목적이라기보다 XCTest를 사용하며 개인적으로 놓쳤던 세세한 부분을 기록하는데 목적이 있어요.

가볍게 작성하는 내용이라 가볍게 읽으시면 좋을 것 같아요 :)

이 글은 Raywenderlich의 Testing in iOS를 기반으로 합니다!

위의 강의를 보면서 놓쳤던 부분을 기록한 연습장 정도로 보셔도 좋을 것 같아요!

XCTest INFO I missed

1. Test를 진행할 때 Scheme 설정

Test를 구현할 때(특히 TDD)를 할 때 중요한 것이 테스트의 속도예요.

테스트를 구현할 때 모든 구현이 끝난 후 마지막에만 실행시켜보는 것이 아니라 실패 테스트를 먼저 작성하고, 테스트를 구현하는 과정 중간중간에 지속적인 테스트가 필요해서 빠른 테스트 속도는 정말 중요해요.

기본적으로 큰 차이를 가져오진 않지만, 테스트 전에 우선 빌드를 하기 때문에 Scheme 설정을 Simulator로 하는 것보단 Mac으로 설정하는 것이 더 빠르다고 하네요!

테스트해보진 못했지만 가능하면 저도 이렇게 세팅하고 진행하려고 해요 :)

2. @testable annotation

프로젝트 코드를 테스트를 위해서는 import 하는 과정이 필요해요.

예를 들어, 테스트 대상의 프로젝트 이름이 AnimalFinder라고 해볼게요.

import AnimalFinder

일반적으로 import 하듯이 테스트 코드에서 프로젝트를 import <Project> 형식으로 한다면 <Project> 내의 object를 초기화(initialize)할 수 없어요.

Swift의 경우 Access Control을 선언해주지 않는다면 Internal로 설정이 되는데요, Test는 다른 module이기 때문에 init을 할 수 없어요.

이를 해결하기 위해서는 외부 module이 접근 가능하도록 프로젝트 내부 객체를 public으로 선언해주던가, @testable 마킹을 해줘야 해요.

라이브러리를 구현하는 중이라면 전자의 방법도 상관이 없지만 일반적인 앱을 구현 중이라면 후자의 방법이 필요해요.

@testable import AnimalFinder

3. Failure Test

TDD에 관한 책이나 글을 읽어보면 가장 중요한 것 중 하나가 실패 테스트를 먼저 해보는 것인데요, 설계를 잘못할 경우 테스트가 의도치 않게 성공하는 경우가 있어요.

그러면 테스트로서의 가치가 전혀 없을 거예요!

XCode에서 단순 compile은 test pass를 띄우기 때문에 성공이 테스트의 성공인지, 테스트 자체가 진행되지 않은 것인지 확인하기 위해서 반드시 failure test를 먼저 띄워볼 필요가 있어요.

4. test 실행 단축키

이건 정말 기본적인 정보이지만 제가 놓치고 있었던 부분이기 때문에 필기했어요.

Control + Option + Command + U를 하면 커서가 놓인 테스트 메서드만 실행할 수 있어요.

여기서 U는 unit test를 의미하며 저는 기존에 Command + U는 사용했었는데 전체 테스트를 실행해요.

5. XCTFail 사용하기

특히 Bool 값을 테스트할 때 좋은 방법이에요.

일반적으로는 Bool 값이 true냐, false냐로 테스트를 구현하기 쉬운데 경우에 따라서 특정 상황에서는 테스트가 fail이 되도록 설계할 필요가 있어요.

반드시 Bool과만 사용해야 하는 것은 아니지만 특정 조건에서 테스트가 Fail이 되도록 설계할 때 XCTFail은 좋은 도구가 될 수 있어요!

6. Optional 처리하기

XCTUnwrap을 통해 Optional을 처리할 수 있어요.

let unwrapedBool = try XCTUnwrap( someOptionalBool )
XCTAssertTrue(unwrapedBool) // unwrap 과정이 없이 이 테스트를 진행하면 문제 발생

그런데 저는 그냥 NotNil 테스트를 하고, 값 자체를 바로 비교해요.

XCTAssertEqual(someOptionalBool, true)

여기서는 unwrap이 중요한 개념이 아니고, 값 자체를 비교하는 로직이기 때문에 테스트에서는 이것으로 충분하다고 생각해요.

7. XCTAssert()

XCTAssert는 XCTAssertTrue와 완전히 같다고 하네요 :)

8. Test method 구현하기

XCTest를 진행하기 위해서 테스트 메서드를 구현할 때 항상 메서드 이름의 시작을 test로 해야 해요.

그래야 그 메서드가 테스트를 위한 메서드인지 XCode가 인지하기 때문이죠.

그동안 생각을 안 해본 부분인데 그 테스트 메서드에 argument(parameter)가 정의될 경우 이 역시 테스트 메서드로 인식하지 못해요.

생각해보면 당연한 것이 이 메서드를 정의하는 건 우리지만 직접 사용하는 것이 아닌데 컴파일러 입장에서 파라미터가 필요한 메서드일 경우 무엇을 넣어줄지 알 수 없어요.

test로 시작해도 테스트 메서드로 인식이 안되어 실행 가능을 의미하는 다이아몬드 표시가 없음

그동안 생각해보지 않은 부분이라 필기했어요 :)

9. Tuple 값 비교하기

튜플을 테스트할 경우 equal을 사용할 때 조심해야 할 것이 있어요.

아래 값은 두 튜플을 단순 비교하는 로직이기 때문에 사용 가능하지만, 위의 Equal 테스트는 사용할 수 없어요.

Tuple은 named type이 아니라 compound type이기 때문인데, 혹시 두 type의 차이를 모르신다면 이번 기회에 알아보면 좋을 것 같아요!

10. Test를 추상화하기

이건 내용 자체보다 목적이 중요한 부분이에요.

예를 들어, 어떤 로직이 Int 와 Double 모두에 적용되는지 확인해야하는 상황이 있다고 가정해볼게요.

가장 단순한 방법은 두 타입의 테스트를 모두 만드는 것이지만 이럴 경우 상황에 따라 무의미한 반복이 계속 2배로 생길 수 있어요.

그래서 두 타입의 상위 개념을 계속 타고 올라가다보면 Int, Double 모두 AdditiveArithmetic에서 나왔음을 알 수 있어요.

그래서 이것을 활용하면 두 테스트를 한 번에 할 수 있는 테스트를 설계할 수 있죠.

public extension Sequence where Element: AdditiveArithmetic { // 공통점을 활용
  ...
}

11. 소수점 비교하기

정수 타입이 아닌 Double, CGFloat 등의 타입 값을 비교할 때 같은 값임에도 불구하고 다르게 표현될 때가 있어요.

부동소수점 방식이기 때문에 발생할 수 있는 문제인데 XCTest에서는 이렇게 소수점 비교를 위해 설정을 할 수 있어요.

위처럼 accuracy를 등록하면 "소수점 12자리 까지만 같으면 같은 것으로 취급하여 테스트를 통과한다" 라고 선언하게 돼요.

소수점 테스트에서 유용하게 사용할 수 있을 것 같아요 :)

이것 외에도 Test Coverage 활용, TDD, Switch 문을 테스트에 더 잘 활용하기 위해 ~= 설정 등 여러 내용이 있지만 여기서는 너무 길어져서 작성하지 않도록 하겠습니다!

혹시 더 자세한 내용이 궁금하시면 도입부에 언급한 자료를 학습해보는 것도 좋을 것 같아요 :)

B_log

Swift로 배우는 전략 패턴 (Strategy Pattern) – Head First 디자인 패턴 기반 설명

Swift로 배우는 전략 패턴 (Strategy Pattern) – Head First 디자인 패턴 기반 설명

전략 패턴이란?

✅ 전략 패턴 요약 정리

책 속 예시: 오리 시뮬레이터

iOS에서의 실제 예: 로그인 전략

1. LoginStrategy 프로토콜 정의

2. 전략 클래스 구현

3. Context 객체: LoginManager

4. ViewController에서 사용

iOS에서 자주 쓰이는 전략 패턴 예시

고급 팁: 클로저로도 전략을 표현할 수 있다

결론

React + Vite 프로젝트 시작하기

React + Vite 프로젝트 생성 방법

✅ 1단계: Node.js 설치

✅ 2단계: Vite + React 프로젝트 생성

✅ 3단계: 의존성 설치 및 개발 서버 실행

✅ 4단계: VSCode에서 프로젝트 열기 (선택 사항)

마무리

다음 글 예고

Belkin 벨킨 썬더볼트 4 C 타입 초고속 케이블

터틀비치 리콘(Turtle Beach Recon) Xbox 컨트롤러 개봉기 및 리뷰

구매 방법 및 가격

구매 당시 가격은 제품 약 39,000원, 배송비 포함 약 42,000원 에 구매했습니다.

박스 외관

박스 열었을 때

컨트롤러

구성품

터틀비치 리콘 컨트롤러의 장단점

데이터 저장: Core Data vs. Realm

개요

Core Data

장점:

단점:

Realm

단점:

결론

[헤드퍼스트 디자인패턴 with Swift] - 2.옵저버 패턴(Observer Pattern)

☀️ 기상 모니터링 애플리케이션 만들기

시스템 파악하기

WeatherData 클래스 살펴보기

‍♂️ measurementsChanged 구현하기

현재 구현 문제 이해하기

옵저버 패턴 사용하기

옵저버 패턴의 정의

Subject(관찰 대상)

Observer(옵저버)

느슨한 결합(Loose Coupling)

디자인 원칙: 상호작용하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다.

기상 스테이션 구현하기

Subject 프로토콜 구현하기

디스플레이 요소 구현하기

☁️ Weather Station 만들기

☕️ Cocoa의 Key-Value Observing을 통해 실제 옵저버 패턴 예시 보기

디자인 원칙: 상속보다는 구성(composition)을 사용한다

[헤드퍼스트 디자인패턴 with Swift] - 1. 전략 패턴(Strategy Pattern)

헤드퍼스트 디자인패턴 시작하기

오리 시뮬레이션 게임 만들기

방법 1. 일반적인 상속 구조 사용하기

방법 2. 프로토콜(인터페이스) 사용하기

디자인 원칙: 애플리케이션에서 달라지는 부분을 찾아내고, 달라지는 부분과 분리한다

디자인 원칙: 구현보다는 인터페이스 맞춰서 프로그래밍한다.

Q. 행동만 나타내는 클래스는 어색해요. 클래스는 원래 어떤 대상을 나타내는 것 아닌가요? 상태, 행동을 모두 포함해야 하는 것 아닌가요?

동적으로 오리의 행동 지정하기

두 클래스의 관계

디자인 원칙: 상속보다는 구성을 활용한다.

iOS에서 전략 패턴 구현해보기

정리

[iOS] - Xcode 단축키 정리

개요

XCode 단축키

Xcode 네비게이터(Navigator) 영역

인스펙터(Inspector) 영역

디버깅 관련

Source Control 관련

iOS Simulator

기본적인 맥 단축키

참고

1. `LoginStrategy` 프로토콜 정의

3. Context 객체: `LoginManager`