17 · 아키텍처와 소프트웨어 공학

// ⚠️ control coupling: 호출부가 내부 분기를 flag로 조종한다
func render(_ item: Item, isCompact: Bool, showsBadge: Bool) { /* if 범벅 */ }

// ✅ 동작이 다르면 타입으로 분리 → 호출부는 무엇을 원하는지만 말한다
protocol ItemRenderer { func render(_ item: Item) }
struct CompactRenderer: ItemRenderer { func render(_ item: Item) { /* ... */ } }
struct DetailRenderer:  ItemRenderer { func render(_ item: Item) { /* ... */ } }

// 모듈 밖으로 노출된 것은 전부 '고칠 때 남을 건드리는' 결합이다.
// Swift의 기본 접근 수준이 internal인 것은 좋은 기본값이다.

import Foundation

// ✅ 밖으로 나가는 것은 최소 DTO와 프로토콜뿐
public struct FeedItem: Sendable, Identifiable {
    public let id: UUID
    public let title: String
    public let createdAt: Date

    // ✅ 이니셜라이저도 의도적으로 노출한다 (public 타입의 기본 init은 internal이다)
    public init(id: UUID, title: String, createdAt: Date) {
        self.id = id
        self.title = title
        self.createdAt = createdAt
    }
}

public protocol FeedLoading: Sendable {
    func load() async throws -> [FeedItem]
}

// ✅ 구현 세부는 전부 internal — 밖에서 알 필요가 없다
struct FeedResponseDTO: Decodable {          // 서버 응답 형태
    let items: [ItemDTO]
    struct ItemDTO: Decodable { let id: String; let title: String }
}

struct FeedMapper {                          // 변환 로직
    func map(_ dto: FeedResponseDTO) -> [FeedItem] { [] }
}

final class FeedCache { }                    // 캐시 구현

// ✅ 공개 진입점 하나만 public
public final class FeedService: FeedLoading {
    private let mapper = FeedMapper()
    private let cache = FeedCache()

    public init() {}
    public func load() async throws -> [FeedItem] { [] }
}

/*  ⚠️ public을 붙이는 순간 그건 계약이 된다 — 바꾸면 소비자가 깨진다.
       "혹시 필요할까 봐" 노출하지 않는다. 필요해지면 그때 올린다.

    ✅ 노출 범위를 좁히는 다른 수단
       · internal            같은 모듈 안에서만 (기본값)
       · fileprivate/private 더 좁게
       · package             같은 패키지 안에서만 (Swift 5.9+)
       · @_spi(Internal)     특정 소비자에게만 (테스트 등)                   */

import Foundation

// control coupling — 호출자가 "내부에서 어떻게 갈라지는지"를 알아야 하는 결합.
// 파라미터가 늘어나면 조합이 폭발하고, 어떤 조합이 유효한지 아무도 모른다.

// ❌ 플래그로 동작을 바꾼다
func fetchBad(useCache: Bool,
              isAdmin: Bool,
              silent: Bool,
              includeDeleted: Bool) async throws -> [Item] {
    // 2⁴ = 16가지 조합. 그중 몇 개가 유효한지 시그니처로는 알 수 없다.
    []
}

// ✅ ① 타입으로 분리하면 분기가 사라진다
protocol FeedSource {
    func load() async throws -> [Item]
}

struct CachedFeedSource: FeedSource {
    let cache: FeedCache
    func load() async throws -> [Item] { [] }
}

struct LiveFeedSource: FeedSource {
    let client: APIClient
    func load() async throws -> [Item] { [] }
}

struct AdminFeedSource: FeedSource {         // 권한별로도 타입이 다르다
    let client: APIClient
    func load() async throws -> [Item] { [] }
}

// ✅ ② 조합이 필요하면 값 타입으로 묶어 유효한 것만 표현한다
struct FeedQuery {
    var scope: Scope = .published
    var ordering: Ordering = .newest

    enum Scope { case published, includingDeleted }   // Bool 두 개보다 명확하다
    enum Ordering { case newest, popular }
}

func fetch(_ query: FeedQuery) async throws -> [Item] { [] }

// ✅ ③ 부수적 관심사(로깅·조용히)는 파라미터가 아니라 데코레이터로
struct SilentFeedSource: FeedSource {
    let wrapped: FeedSource
    func load() async throws -> [Item] {
        (try? await wrapped.load()) ?? []     // 실패를 삼킨다
    }
}

struct Item {}
final class FeedCache {}
final class APIClient {}

import Foundation

// common coupling — 여러 모듈이 같은 전역 상태를 읽고 쓰는 결합.
// 누가 언제 바꾸는지 추적할 수 없고, 테스트가 서로 간섭한다.

// ❌ 전역 가변 싱글턴
final class BadSession {
    static let shared = BadSession()
    var currentUser: User?            // 💥 아무나 어디서나 바꾼다
    var authToken: String?
}
// 문제
//   · 이 값을 누가 바꿨는지 추적 불가
//   · 테스트마다 상태가 남아 순서에 의존하게 된다
//   · 동시성 안전하지 않다
//   · 의존이 시그니처에 안 드러나 숨은 결합이 된다

// ✅ ① 명시적 주입 — 의존이 타입에 보인다
protocol SessionReading: Sendable {
    var currentUser: User? { get async }
}

actor Session: SessionReading {
    private var user: User?
    var currentUser: User? { user }

    func signIn(_ u: User) { user = u }
    func signOut() { user = nil }
}

struct ProfileService {
    private let session: SessionReading      // ✅ 필요한 최소 인터페이스만
    init(session: SessionReading) { self.session = session }

    func loadProfile() async throws -> Profile {
        guard let user = await session.currentUser else { throw AppError.notSignedIn }
        return try await fetch(user.id)
    }
    private func fetch(_ id: UUID) async throws -> Profile { Profile() }
}

// ✅ ② 테스트가 쉬워진다 — 전역을 건드리지 않는다
func test_로그인_안된_경우() async {
    let service = ProfileService(session: StubSession(user: nil))
    // 다른 테스트에 영향을 주지 않는다
}

struct StubSession: SessionReading {
    let user: User?
    var currentUser: User? { user }
}

// ⚠️ 싱글턴 자체가 나쁜 게 아니다. '전역 가변 상태'가 문제다.
//    불변 설정(Configuration)이나 actor로 격리된 것은 괜찮다.

struct User { let id: UUID }
struct Profile {}
enum AppError: Error { case notSignedIn }

import Foundation

// 응집도 = 한 모듈의 요소들이 하나의 책임에 모여 있는 정도.
// 판별 기준은 "이 타입이 바뀌는 이유가 몇 개인가"다(SRP).

// ❌ 바뀌는 이유가 넷이다
final class BadUserManager {
    // ① 서버 API가 바뀌면
    func fetchUser(id: UUID) async throws -> User { User() }

    // ② DB 스키마가 바뀌면
    func saveToDatabase(_ user: User) throws {}

    // ③ 표시 형식이 바뀌면
    func formattedName(_ user: User) -> String { "" }

    // ④ 검증 규칙이 바뀌면
    func validate(_ email: String) -> Bool { true }
}

// ✅ 이유별로 쪼갠다
struct UserAPI {                       // 서버 계약이 바뀔 때만
    func fetch(id: UUID) async throws -> User { User() }
}

struct UserRepository {                // 저장 방식이 바뀔 때만
    func save(_ user: User) throws {}
    func load(id: UUID) throws -> User? { nil }
}

struct UserFormatter {                 // 표시 규칙이 바뀔 때만
    func displayName(_ user: User) -> String { "" }
}

struct EmailValidator {                // 검증 규칙이 바뀔 때만
    func isValid(_ email: String) -> Bool { true }
}

// ⚠️ 반대 방향 과잉도 조심한다. 함께 바뀌는 것을 억지로 쪼개면
//    변경할 때마다 여러 파일을 오가야 해서 오히려 결합이 는다.
//    "함께 바뀌는 것은 함께 둔다"가 응집의 정의다.

// ✅ 판별 질문
//   "이 파일을 여는 이유가 몇 가지인가?"
//   "이 타입을 고치는 사람이 서로 다른 역할인가?" (서버 담당 vs 디자인 담당)

struct User {}

# import 의존은 없는데 항상 같이 바뀌는 두 파일 = 이름 없는 결합.
# 코드로는 안 보이지만 실제로는 묶여 있다.

# ✅ ① 먼저 파일별 변경 빈도를 센다 — 자주 바뀌는 파일이 후보다
git log --format=format: --name-only --since="6 months ago" \
  | grep -v '^$' \
  | sort | uniq -c | sort -rn | head -30
#   각 파일의 변경 빈도 — 자주 바뀌는 파일이 후보다

# ✅ ② 실제로 '같은 커밋에' 등장한 쌍을 뽑는다
git log --format='%H' --since="6 months ago" | while read commit; do
  git show --format= --name-only "$commit" \
    | grep '\.swift$' | sort | paste -sd, -
done | sort | uniq -c | sort -rn | head -20

# 출력 예:
#   47  Sources/Feed/FeedViewModel.swift,Sources/Analytics/EventLogger.swift
#   → import 관계가 없는데 47번이나 함께 바뀌었다 = 숨은 결합

# ✅ ③ 해석과 대응
#   · 이벤트 이름 문자열을 양쪽에서 하드코딩하고 있다
#     → 공유 타입(enum)으로 끌어올려 명시적 의존으로 만든다
#   · 서버 응답 필드를 두 곳에서 각자 파싱한다
#     → DTO를 한 곳에 두고 공유한다
#   · 같은 비즈니스 규칙이 두 곳에 복제돼 있다
#     → 한 곳으로 모은다

# ✅ ④ 도구를 쓰면 더 쉽다
#    · code-maat (Adam Tornhill) — logical coupling 분석
#    · CodeScene — 시각화

# ⚠️ 함께 바뀌는 것이 항상 나쁜 건 아니다.
#    한 기능의 뷰·뷰모델·테스트가 함께 바뀌는 건 정상이다(응집).
#    문제는 '서로 다른 관심사'가 함께 바뀔 때다.

// ⚠️ 로직 안에서 Date()를 부르면 테스트가 매번 달라진다
func isExpired(_ token: Token) -> Bool { token.expiry < Date() }

// ✅ 순수: 시각을 인자로 받는다 → 테스트에서 원하는 시각을 넣는다
func isExpired(_ token: Token, now: Date) -> Bool { token.expiry < now }

// 셸(효과)에서만 실제 시계를 읽어 코어에 값으로 주입한다
let expired = isExpired(token, now: Date())   // 경계에서 한 번

import Foundation

// 순수 함수는 같은 입력에 항상 같은 출력을 낸다.
// 그러려면 함수 안에서 '바깥'을 읽으면 안 된다.

// ❌ 숨은 입력이 셋이다 — 테스트할 수 없다
struct BadPricing {
    func total(items: [Item], coupon: Coupon?) -> Money {
        let base = items.reduce(Money.zero) { $0 + $1.price }

        guard let coupon,
              coupon.expiresAt > Date()                    // ① 현재 시각
        else { return base }

        let rate = RemoteConfig.shared.maxDiscountRate     // ② 전역 설정
        let bonus = Bool.random() ? 0.05 : 0               // ③ 난수

        let applied = Decimal(min(coupon.rate, rate) + bonus)
        return base * (1 - applied)
    }
}

// ✅ 필요한 모든 것을 인자로 받는다
struct Pricing {
    static func total(items: [Item],
                      coupon: Coupon?,
                      now: Date,
                      maxDiscountRate: Double) -> Money {
        let base = items.reduce(Money.zero) { $0 + $1.price }
        guard let coupon, coupon.expiresAt > now else { return base }
        let applied = Decimal(min(coupon.rate, maxDiscountRate))
        return base * (1 - applied)
    }
}

// ✅ 테스트가 목 없이 값 비교만으로 끝난다
func test_만료된_쿠폰은_무시된다() {
    let now = Date(timeIntervalSince1970: 1_800_000_000)
    let expired = Coupon(rate: 0.2, expiresAt: now.addingTimeInterval(-1))

    let result = Pricing.total(items: [Item(price: 1000)],
                               coupon: expired,
                               now: now,
                               maxDiscountRate: 0.3)
    assert(result == 1000)
}

// ⚠️ 함수 안에서 부르면 안 되는 것들
//    Date() · UUID() · Bool.random() · UserDefaults · 전역 싱글턴
//    Locale.current · TimeZone.current · FileManager · URLSession

struct Item { let price: Money }
struct Coupon { let rate: Double; let expiresAt: Date }
typealias Money = Decimal
extension Decimal { static var zero: Decimal { 0 } }
enum RemoteConfig { static let shared = RemoteConfigImpl() }
struct RemoteConfigImpl { let maxDiscountRate = 0.3 }

import Foundation
import Combine

// Functional Core, Imperative Shell:
//   안쪽(코어)은 순수한 계산, 바깥쪽(셸)만 효과를 낸다.

// ── 코어: 순수. 테스트가 값 비교로 끝난다.
struct CheckoutCore {
    struct Input {
        let items: [Item]
        let coupon: Coupon?
        let now: Date
        let userTier: Tier
    }
    struct Output: Equatable {
        let total: Decimal
        let appliedDiscount: Decimal
        let warnings: [String]
    }

    static func compute(_ input: Input) -> Output {
        let base = input.items.reduce(Decimal.zero) { $0 + $1.price }
        var discount = Decimal.zero
        var warnings: [String] = []

        if let coupon = input.coupon {
            if coupon.expiresAt <= input.now {
                warnings.append("쿠폰이 만료되었습니다")
            } else {
                discount = base * Decimal(coupon.rate)
            }
        }
        if input.items.isEmpty { warnings.append("장바구니가 비어 있습니다") }

        return Output(total: base - discount,
                      appliedDiscount: discount,
                      warnings: warnings)
    }
}

// ── 셸: 효과만 담당. 로직은 코어에 위임한다.
@MainActor
final class CheckoutViewModel: ObservableObject {
    @Published private(set) var output: CheckoutCore.Output?

    private let repository: CartRepository      // 효과 (네트워크·DB)
    private let now: () -> Date                 // 효과 (시계)

    init(repository: CartRepository, now: @escaping () -> Date = Date.init) {
        self.repository = repository
        self.now = now
    }

    func refresh() async throws {
        let items = try await repository.items()          // 효과
        let coupon = try await repository.activeCoupon()  // 효과

        output = CheckoutCore.compute(                    // 순수 계산
            .init(items: items, coupon: coupon, now: now(), userTier: .basic))
    }
}

// ⚠️ 순수 코어를 굳이 actor로 감싸지 않는다 — 불필요한 suspension hop과
//    재진입 복잡성만 늘어난다. 순수 함수는 애초에 스레드 안전하다.

struct Item { let price: Decimal }
struct Coupon { let rate: Double; let expiresAt: Date }
enum Tier { case basic, premium }
protocol CartRepository {
    func items() async throws -> [Item]
    func activeCoupon() async throws -> Coupon?
}

import Foundation

// 순수 함수는 상태가 없으므로 이미 스레드 안전하다.
// actor로 감싸면 얻는 것 없이 suspension hop과 재진입 복잡성만 는다.

// ❌ 계산만 하는 것을 actor로
actor BadCalculator {
    func total(_ items: [Item]) -> Decimal {
        items.reduce(0) { $0 + $1.price }
    }
}
// 호출부: await calculator.total(items)
//   · 매 호출마다 actor hop (스케줄링 비용)
//   · await가 생겨 호출부가 async가 되어야 한다
//   · 얻는 안전성은 0 (애초에 공유 상태가 없다)

// ✅ 순수 함수는 그냥 함수로 — 어디서든 동시에 불러도 안전하다
enum Calculator {
    static func total(_ items: [Item]) -> Decimal {
        items.reduce(0) { $0 + $1.price }
    }
}
// 호출부: Calculator.total(items)   — 동기, 비용 0

// ✅ actor가 필요한 경우: '가변 상태를 보호'할 때뿐이다
actor OrderQueue {
    private var pending: [Order] = []          // ← 가변 상태가 있다

    func enqueue(_ order: Order) { pending.append(order) }
    func drain() -> [Order] { defer { pending = [] }; return pending }
}

// ✅ 상태를 가진 타입 안에서도 계산은 순수 함수에 위임한다
actor Cart {
    private var items: [Item] = []

    func add(_ item: Item) { items.append(item) }

    var total: Decimal {
        Calculator.total(items)                // ✅ 순수 함수 재사용
    }
}

// 판별 질문: "이 타입에 var 저장 프로퍼티가 있고, 여러 곳에서 동시에 접근하는가?"
//   아니오 → 그냥 함수/struct
//   예     → actor 또는 락

struct Item { let price: Decimal }
struct Order {}

import Testing
import Foundation

// 순수 코어는 테스트가 값 비교라 빠르고 결정적이다 → 많이 쓴다.
// 셸은 목·환경이 필요해 느리다 → 소수만 쓴다.

// ── 코어 테스트: 대량으로, 밀리초 단위
@Test(arguments: [
    (9_999,  0.0),
    (10_000, 0.1),
    (49_999, 0.1),
    (50_000, 0.2),
    (999_999, 0.2),
])
func 할인율_경계값(amount: Int, expected: Double) {
    #expect(Pricing.discountRate(for: Decimal(amount)) == Decimal(expected))
}

@Test func 만료된_쿠폰은_경고를_남긴다() {
    let now = Date(timeIntervalSince1970: 1_800_000_000)
    let output = CheckoutCore.compute(.init(
        items: [Item(price: 1000)],
        coupon: Coupon(rate: 0.2, expiresAt: now.addingTimeInterval(-1)),
        now: now))

    #expect(output.total == 1000)
    #expect(output.warnings.contains("쿠폰이 만료되었습니다"))
}

@Test func 빈_장바구니() {
    let output = CheckoutCore.compute(.init(items: [], coupon: nil, now: .now))
    #expect(output.total == 0)
    #expect(output.warnings.count == 1)
}
// … 이런 케이스를 수십 개 넣어도 전체가 1초 안에 끝난다

// ── 셸 테스트: 소수만. '배선이 맞는가'만 확인한다.
@Test func 뷰모델이_저장소와_코어를_연결한다() async throws {
    let repository = StubCartRepository(items: [Item(price: 1000)], coupon: nil)
    let viewModel = await CheckoutViewModel(repository: repository,
                                            now: { Date(timeIntervalSince1970: 0) })

    try await viewModel.refresh()

    #expect(await viewModel.output?.total == 1000)
}
// 계산 규칙은 이미 코어 테스트가 검증했다 — 여기서 또 검증하지 않는다

struct StubCartRepository: CartRepository {
    let items: [Item]; let coupon: Coupon?
    func items() async throws -> [Item] { items }
    func activeCoupon() async throws -> Coupon? { coupon }
}

struct Item { let price: Decimal }
struct Coupon { let rate: Double; let expiresAt: Date }
enum Pricing { static func discountRate(for a: Decimal) -> Decimal { 0 } }
enum CheckoutCore {
    struct Input { let items: [Item]; let coupon: Coupon?; let now: Date }
    struct Output { let total: Decimal; let warnings: [String] }
    static func compute(_ i: Input) -> Output { Output(total: 0, warnings: []) }
}
protocol CartRepository {
    func items() async throws -> [Item]
    func activeCoupon() async throws -> Coupon?
}
@MainActor final class CheckoutViewModel {
    var output: CheckoutCore.Output?
    init(repository: CartRepository, now: @escaping () -> Date) {}
    func refresh() async throws {}
}

// Interface 모듈 — 고수준이 소유하는 추상
protocol PaymentGateway { func charge(_ amount: Decimal) async throws }

// 고수준 정책 — Stripe를 전혀 모른다 (컴파일타임 의존 없음)
struct Checkout {
    let gateway: PaymentGateway            // ← 추상에만 의존 (DIP)
    init(gateway: PaymentGateway) { self.gateway = gateway }   // ← 주입 (DI)
    func pay(_ amount: Decimal) async throws { try await gateway.charge(amount) }
}

// Implementation 모듈 — 추상을 구현 (소스 의존이 위를 향한다)
struct StripeGateway: PaymentGateway { func charge(_ amount: Decimal) async throws { /* ... */ } }

// composition root에서 배선
let checkout = Checkout(gateway: StripeGateway())
// 테스트: 같은 추상에 목을 주입 (네트워크 없이)
struct MockGateway: PaymentGateway { func charge(_ amount: Decimal) async throws {} }
let sut = Checkout(gateway: MockGateway())

import UIKit

// 생성자 주입은 "이 타입이 무엇 없이는 못 산다"를 컴파일러가 강제하게 한다.

// ✅ 의존이 시그니처에 전부 드러난다
struct CheckoutService {
    private let repository: OrderRepository
    private let payment: PaymentGateway
    private let clock: () -> Date

    init(repository: OrderRepository,
         payment: PaymentGateway,
         clock: @escaping () -> Date = Date.init) {
        self.repository = repository
        self.payment = payment
        self.clock = clock
    }

    func checkout(_ order: Order) async throws -> Receipt {
        let receipt = try await payment.charge(order.total)
        try await repository.save(order, at: clock())
        return receipt
    }
}
// 장점
//   · 초기화 후 항상 유효한 상태 (Optional·IUO가 필요 없다)
//   · 테스트에서 교체가 자명하다
//   · 의존을 빠뜨리면 컴파일 에러

// ⚠️ 프로퍼티 주입은 생성 시점을 제어할 수 없을 때만
final class CheckoutViewController: UIViewController {
    // 스토리보드가 init을 대신 부르므로 생성자 주입이 불가능하다
    var service: CheckoutService!          // 어쩔 수 없는 경우

    // ✅ 코드로 만든다면 생성자 주입이 가능하다
    init(service: CheckoutService) {
        self.service = service
        super.init(nibName: nil, bundle: nil)
    }
    required init?(coder: NSCoder) { fatalError("코드로 생성하세요") }
}

// ✅ 의존이 많아지면 그 자체가 신호다 — 타입이 너무 많은 일을 한다
//    5개를 넘어가면 쪼갤 때가 된 것이다

protocol OrderRepository { func save(_ o: Order, at date: Date) async throws }
protocol PaymentGateway { func charge(_ amount: Decimal) async throws -> Receipt }
struct Order { let total: Decimal }
struct Receipt {}

import Foundation

// ── Domain 모듈 (고수준 정책) — 여기가 추상의 소유자다
//    "내가 필요한 건 이것뿐"을 정의한다

/// ✅ 고수준이 필요로 하는 최소 인터페이스만 (ISP)
public protocol OrderPersisting: Sendable {
    func save(_ order: Order) async throws
    func find(id: Order.ID) async throws -> Order?
}

public struct CheckoutService {
    private let persistence: OrderPersisting     // ✅ Domain이 정의한 추상에 의존
    public init(persistence: OrderPersisting) { self.persistence = persistence }

    public func checkout(_ order: Order) async throws {
        try await persistence.save(order)
    }
}

// ── Infrastructure 모듈 (저수준 세부) — Domain을 import 한다
//    의존 방향이 뒤집혔다: 저수준 → 고수준

struct CoreDataOrderStore: OrderPersisting {
    func save(_ order: Order) async throws { }
    func find(id: Order.ID) async throws -> Order? { nil }
}

struct APIOrderStore: OrderPersisting {
    func save(_ order: Order) async throws { }
    func find(id: Order.ID) async throws -> Order? { nil }
}

// ❌ 저수준이 인터페이스를 소유하면 역전이 아니다
//    (Domain이 Networking·CoreData를 import하게 된다)
//    protocol NetworkClient { ... }   ← Networking 모듈에 있고
//    struct CheckoutService { let client: NetworkClient }   ← Domain이 그걸 의존

// ❌ 인터페이스가 구현에 맞춰져 있어도 역전이 아니다 — 이름만 프로토콜이다
protocol BadOrderStore {
    func executeSQL(_ query: String) throws -> [[String: Any]]   // 💥 SQL이 새어 나온다
    var managedObjectContext: AnyObject { get }                  // 💥 Core Data가 새어 나온다
}

// ✅ 핵심 판별: "이 프로토콜을 보고 구현 기술을 알 수 있는가?"
//    알 수 있으면 추상화가 실패한 것이다.

public struct Order: Identifiable, Sendable {
    public let id: UUID
}

import Foundation

// 컨테이너에서 꺼내 쓰면 의존이 시그니처에 드러나지 않는다.
// 컴파일러가 도와줄 수 없고, 런타임에야 누락을 알게 된다.

// ❌ Service Locator — 무엇이 필요한지 밖에서 알 수 없다
final class BadCheckoutService {
    func checkout(_ order: Order) async throws {
        let repo = Container.shared.resolve(OrderRepository.self)!   // 💥 런타임 크래시 가능
        let payment = Container.shared.resolve(PaymentGateway.self)!
        _ = try await payment.charge(order.total)
        try await repo.save(order)
    }
}
/*  문제
      · 이 타입을 쓰려면 무엇을 등록해야 하는지 코드를 읽어야 안다
      · 테스트에서 전역 컨테이너를 바꿔야 해서 테스트끼리 간섭한다
      · 등록을 빠뜨리면 런타임에 크래시한다
      · 의존 그래프가 코드에 안 드러나 리팩터링이 어렵다                    */

// ✅ 생성자 주입 — 컴파일러가 검증한다
struct CheckoutService {
    let repository: OrderRepository
    let payment: PaymentGateway

    func checkout(_ order: Order) async throws {
        _ = try await payment.charge(order.total)
        try await repository.save(order)
    }
}

// ✅ 조립은 앱 진입점(Composition Root) 한 곳에서만 한다
@MainActor
enum CompositionRoot {
    static func makeCheckoutScreen() -> CheckoutViewController {
        let repository = CoreDataOrderRepository()
        let payment = StripeGateway(apiClient: makeAPIClient())
        let service = CheckoutService(repository: repository, payment: payment)
        return CheckoutViewController(service: service)
    }

    private static func makeAPIClient() -> APIClient { APIClient() }
}
// 의존 그래프 전체가 이 한 파일에 보인다 — 읽으면 구조가 이해된다

// ⚠️ DI 컨테이너가 항상 나쁜 건 아니다. 모듈이 아주 많아 수동 조립이
//    관리 불가능해질 때는 도구가 필요하다. 다만 그때도 '조립은 한 곳에서'를 지킨다.

protocol OrderRepository { func save(_ o: Order) async throws }
protocol PaymentGateway { func charge(_ a: Decimal) async throws -> Receipt }
struct Order { let total: Decimal }
struct Receipt {}
struct CoreDataOrderRepository: OrderRepository { func save(_ o: Order) async throws {} }
struct StripeGateway: PaymentGateway {
    let apiClient: APIClient
    func charge(_ a: Decimal) async throws -> Receipt { Receipt() }
}
final class APIClient {}
enum Container { static let shared = ContainerImpl() }
struct ContainerImpl { func resolve<T>(_ t: T.Type) -> T? { nil } }
@MainActor final class CheckoutViewController {
    init(service: CheckoutService) {}
}

import Foundation

// 구현이 하나뿐이고 교체·테스트 대체가 필요 없으면 프로토콜은 순손해다.
// 점프가 한 겹 늘고, 정의를 찾아 파일을 오가야 한다.

// ❌ 구현이 영원히 하나인데 만든 프로토콜
protocol DateFormatting {
    func string(from date: Date) -> String
}
struct AppDateFormatter: DateFormatting {
    func string(from date: Date) -> String { "" }
}
// 이 프로토콜이 존재해서 얻는 것: 없다
// 잃는 것: 파일 하나, 점프 한 겹, "구현체가 여럿인가?" 하는 혼란

// ✅ 구체 타입을 그대로 주입한다
struct ReceiptRenderer {
    let formatter: AppDateFormatter        // 구체 타입
    func render(_ receipt: Receipt) -> String { "" }
}

// ✅ 프로토콜이 정당한 경우
//   ① 실제로 구현이 여럿이다
protocol PaymentGateway {
    func charge(_ amount: Decimal) async throws -> Receipt
}
struct StripeGateway: PaymentGateway {
    func charge(_ amount: Decimal) async throws -> Receipt { Receipt() }
}
struct TossGateway: PaymentGateway {
    func charge(_ amount: Decimal) async throws -> Receipt { Receipt() }
}

//   ② 테스트에서 반드시 대체해야 한다 (네트워크·시계·파일)
protocol OrderRepository {
    func save(_ order: Order) async throws
}

//   ③ 모듈 경계에서 의존 방향을 뒤집어야 한다 (DIP)

// ✅ 순수 함수는 프로토콜 없이도 테스트된다 — 대체할 게 없기 때문이다
enum Pricing {
    static func total(_ items: [Item]) -> Decimal {
        items.reduce(0) { $0 + $1.price }
    }
}
func test_합계() {
    assert(Pricing.total([Item(price: 100), Item(price: 200)]) == 300)
    // 목도, 프로토콜도, 주입도 필요 없다
}

// 판별: "이 프로토콜의 구현체를 지금 두 개 이상 쓸 수 있는가?"
//   아니오이고 테스트 대체도 불필요 → 구체 타입

struct Receipt {}; struct Order {}; struct Item { let price: Decimal }

// ⚠️ 공유 가변 + 동시 쓰기 → 갱신 유실 (이 공유·변이가 Swift 6에서는 컴파일 에러로 차단됨)
final class Counter { var value = 0 }
// 두 태스크가 c.value += 1 을 동시에 → read-modify-write가 겹쳐 값이 샌다

// ✅ actor로 접근을 직렬화
actor SafeCounter {
    private var value = 0
    func increment() { value += 1 }        // 이 메서드 하나는 원자적
    var current: Int { value }
}

// ⚠️ 재진입 함정: await를 가로지르면 원자성이 깨진다
actor Bank {
    private var balance = 0
    func withdraw(_ n: Int) async {
        guard balance >= n else { return }  // 확인
        await audit()                       // ← 여기서 다른 withdraw가 끼어들 수 있다
        balance -= n                        // 확인이 더는 유효하지 않을 수 있음 → 재확인 필요
    }
}

import Foundation

// 공유 가변 상태의 네 조건(공유·가변·동시·쓰기) 중 하나만 끊어도 문제가 사라진다.
// 가장 싼 방법은 '가변'을 끊는 것이다.

// ✅ 값 타입 + let — 애초에 공유도 변경도 없다
struct Order: Sendable, Equatable {
    let id: UUID
    let items: [Item]
    let createdAt: Date

    // 변경은 '새 값을 만드는' 방식으로
    func adding(_ item: Item) -> Order {
        Order(id: id, items: items + [item], createdAt: createdAt)
    }
}

struct Item: Sendable, Equatable {
    let sku: String
    let quantity: Int
}

// ✅ 상태 전이를 enum으로 표현하면 유효하지 않은 조합이 아예 없다
enum LoadState: Sendable, Equatable {
    case idle
    case loading
    case loaded([Item])
    case failed(String)
}
// ❌ 이렇게 두면 isLoading=true인데 error도 있는 상태가 표현 가능하다
//    struct BadState { var isLoading: Bool; var items: [Item]; var error: String? }

// ✅ 참조 타입이 필요하면 불변으로 만들어 공유를 안전하게 한다
final class Configuration: Sendable {
    let baseURL: URL
    let timeout: TimeInterval
    init(baseURL: URL, timeout: TimeInterval) {
        self.baseURL = baseURL
        self.timeout = timeout
    }
}

// ✅ 스냅샷도 그냥 대입이다
func snapshotting(_ order: Order) {
    let before = order              // 복사
    let after = order.adding(Item(sku: "X", quantity: 1))
    assert(before != after)         // 원본은 그대로
}

import Foundation
import Combine

// 없앨 수 없는 공유 상태는 '한 곳'이 소유하고 나머지는 그곳을 통해서만 접근한다.

// ❌ 여러 곳이 각자 상태를 들고 동기화하려 한다
final class BadCartA { var items: [Item] = [] }
final class BadCartB { var items: [Item] = [] }   // 💥 어느 게 진실인가?

// ✅ single source of truth — 소유자는 하나
actor CartStore {
    private var items: [Item] = []
    private var continuations: [UUID: AsyncStream<[Item]>.Continuation] = [:]

    func add(_ item: Item) {
        items.append(item)
        broadcast()
    }

    func remove(sku: String) {
        items.removeAll { $0.sku == sku }
        broadcast()
    }

    var snapshot: [Item] { items }

    /// 관찰자는 스트림으로 변경을 받는다 — 각자 사본을 유지하지 않는다
    func observe() -> AsyncStream<[Item]> {
        let id = UUID()
        return AsyncStream { continuation in
            continuations[id] = continuation
            continuation.yield(items)
            continuation.onTermination = { _ in
                Task { await self.removeObserver(id) }
            }
        }
    }

    private func removeObserver(_ id: UUID) { continuations[id] = nil }
    private func broadcast() { continuations.values.forEach { $0.yield(items) } }
}

// ✅ UI 상태는 @MainActor로 격리한다
@MainActor
final class CartViewModel: ObservableObject {
    @Published private(set) var items: [Item] = []
    private let store: CartStore

    init(store: CartStore) {
        self.store = store
        // ⚠️ self를 강하게 캡처하고 스트림이 끝나지 않으면 ViewModel이 해제되지 않는다.
        //    태스크를 보관해 두고 deinit에서 취소해야 한다.
        observation = Task { [weak self] in
            for await snapshot in await store.observe() { self?.items = snapshot }
        }
    }

    private var observation: Task<Void, Never>?
    deinit { observation?.cancel() }
}

struct Item: Sendable { let sku: String }

import Foundation
import os

// 락을 쥔 채 남의 코드를 부르면 그쪽이 무엇을 할지 알 수 없다.
// 다른 락을 잡으면 교착이고, 우선순위가 낮으면 역전이다.

final class MetricsStore {
    private let state = OSAllocatedUnfairLock(initialState: [String: Int]())
    weak var delegate: MetricsDelegate?

    // ❌ 락 안에서 외부 콜백
    func recordBad(_ key: String) {
        state.withLock { dict in
            dict[key, default: 0] += 1
            self.delegate?.didUpdate()        // 💥 이 안에서 무엇을 할지 모른다
        }
    }

    // ✅ 락 안에서는 순수 계산만, 부수효과는 밖에서
    func record(_ key: String) {
        let snapshot: [String: Int] = state.withLock { dict in
            dict[key, default: 0] += 1
            return dict                        // 필요한 값만 복사해 나온다
        }
        delegate?.didUpdate(snapshot)          // ✅ 락을 놓은 뒤
    }
}

// actor도 같은 원리다 — await 지점이 재진입 창을 연다
actor OrderProcessor {
    private var stock: [String: Int] = [:]

    // ❌ 상태 확인과 변경 사이에 await
    func processBad(_ order: Order) async throws {
        guard stock[order.sku, default: 0] >= order.quantity else { throw ShopError.soldOut }
        await payment.charge(order)            // ⚠️ 여기서 다른 호출이 끼어든다
        stock[order.sku]! -= order.quantity    // 이미 다 팔렸을 수 있다
    }

    // ✅ 상태 변경은 await 없는 구간에서 원자적으로
    func reserve(_ order: Order) throws {
        let left = stock[order.sku, default: 0]
        guard left >= order.quantity else { throw ShopError.soldOut }
        stock[order.sku] = left - order.quantity   // await 없음 → 끼어들 틈 없음
    }

    func release(_ order: Order) { stock[order.sku, default: 0] += order.quantity }
}

// 긴 흐름은 actor 밖에서 조립하고, 실패하면 보상한다
func placeOrder(_ order: Order, in processor: OrderProcessor) async throws {
    try await processor.reserve(order)
    do { try await payment.charge(order) }
    catch { await processor.release(order); throw error }
}

protocol MetricsDelegate: AnyObject {
    func didUpdate()
    func didUpdate(_ snapshot: [String: Int])
}
struct Order { let sku: String; let quantity: Int }
enum ShopError: Error { case soldOut }
enum payment { static func charge(_ o: Order) async throws {} }

import Foundation

// 전역 가변 상태는 어디서 바뀌는지 추적할 수 없고 동시성 안전하지도 않다.
// Swift 6 strict concurrency는 이걸 컴파일 타임에 잡아 준다.

// ❌ Swift 6에서 컴파일 에러가 난다
//    error: static property 'pendingEvents' is not concurrency-safe because
//           it is nonisolated global shared mutable state
// final class BadAnalytics {
//     static var pendingEvents: [Event] = []
// }

// ✅ ① 불변으로 만든다 (가장 단순)
enum Config {
    static let apiBaseURL = URL(string: "https://api.example.com")!
    static let timeout: TimeInterval = 30
}

// ✅ ② 가변이 필요하면 actor로 격리한다
actor EventQueue {
    static let shared = EventQueue()
    private var pending: [Event] = []

    func enqueue(_ event: Event) { pending.append(event) }

    func drain(upTo limit: Int) -> [Event] {
        let batch = Array(pending.prefix(limit))
        pending.removeFirst(batch.count)
        return batch
    }
}

// ✅ ③ UI 관련이면 @MainActor
@MainActor
final class AppRouter {
    static let shared = AppRouter()
    private(set) var currentScreen: Screen = .home
    func navigate(to screen: Screen) { currentScreen = screen }
}

// ✅ ④ 정말 락으로 해야 하면 근거를 남긴 @unchecked
import os
/// 스레드 안전성: 모든 접근이 `state` 락을 통과한다. 아래가 유일한 진입점이다.
final class Counter: @unchecked Sendable {
    static let shared = Counter()
    private let state = OSAllocatedUnfairLock(initialState: 0)
    func increment() { state.withLock { $0 += 1 } }
    func value() -> Int { state.withLock { $0 } }
}

/*  ✅ strict concurrency 켜기
      Package.swift:
        swiftSettings: [.enableUpcomingFeature("StrictConcurrency")]
      Xcode:
        Build Settings → Swift Compiler - Concurrency
          → Strict Concurrency Checking → Complete                          */

struct Event: Sendable {}
enum Screen { case home, detail }

// ⚠️ 구현이 평생 하나뿐인데 "테스트 때문에" 뽑은 프로토콜 — 순손해
protocol DateFormatterProviding { func string(from: Date) -> String }
struct DefaultDateFormatterProvider: DateFormatterProviding { /* ... */ }

// ✅ 교체·다형성·테스트 대체가 실제로 필요 없으면 구체 타입 + 순수 함수로 충분
enum DateText {
    static func short(_ date: Date, calendar: Calendar) -> String { /* ... */ }
}
// 순수 함수라 목 없이도 테스트가 결정적 (Q2와 같은 원리)

import Foundation

// 두 번의 유사함은 우연일 때가 많다(coincidental duplication).
// 세 번째에서야 '변화 축'이 보인다.

// 1회차 — 그냥 쓴다
func loadProfile() async throws -> Profile {
    var request = URLRequest(url: URL(string: "https://api.example.com/profile")!)
    request.setValue("application/json", forHTTPHeaderField: "Accept")
    let (data, _) = try await URLSession.shared.data(for: request)
    return try JSONDecoder().decode(Profile.self, from: data)
}

// 2회차 — 비슷해 보이지만 아직 추상화하지 않는다
func loadFeed() async throws -> [Post] {
    var request = URLRequest(url: URL(string: "https://api.example.com/feed")!)
    request.setValue("application/json", forHTTPHeaderField: "Accept")
    let (data, _) = try await URLSession.shared.data(for: request)
    return try JSONDecoder().decode([Post].self, from: data)
}

// 3회차 — 이제 공통 축이 보인다: (경로, 응답 타입)
//   그리고 세 번을 보니 헤더·디코딩 전략도 늘 같다는 걸 알겠다
struct APIClient {
    private let baseURL: URL
    private let session: URLSession
    private let decoder: JSONDecoder

    func get<T: Decodable>(_ path: String, as type: T.Type) async throws -> T {
        var request = URLRequest(url: baseURL.appending(path: path))
        request.setValue("application/json", forHTTPHeaderField: "Accept")
        let (data, response) = try await session.data(for: request)
        try validate(response)
        return try decoder.decode(T.self, from: data)
    }

    private func validate(_ response: URLResponse) throws {}
}

// 사용
func loadAll(_ client: APIClient) async throws {
    let profile = try await client.get("/profile", as: Profile.self)
    let feed = try await client.get("/feed", as: [Post].self)
    let orders = try await client.get("/orders", as: [Order].self)
    _ = (profile, feed, orders)
}

// ⚠️ 2회차에서 뽑았다면 '경로만 다른 함수'를 만들었을 것이고,
//    3회차에서 헤더가 다른 요청이 나타나면 플래그를 덧대게 됐을 것이다.

struct Profile: Decodable {}; struct Post: Decodable {}; struct Order: Decodable {}

import Foundation

// 프로토콜은 공짜가 아니다. 정의 파일이 하나 늘고, 구현을 찾으려면
// "이 프로토콜을 준수하는 게 뭐지?"를 매번 되물어야 한다.

// ❌ 구현이 하나뿐이고 앞으로도 하나일 것
protocol StringTrimming {
    func trim(_ s: String) -> String
}
struct DefaultTrimmer: StringTrimming {
    func trim(_ s: String) -> String { s.trimmingCharacters(in: .whitespaces) }
}
// 얻는 것: 없음. 잃는 것: 파일·점프·간접 디스패치.

// ✅ 그냥 함수나 구체 타입
enum StringUtil {
    static func trim(_ s: String) -> String {
        s.trimmingCharacters(in: .whitespaces)
    }
}

// ✅ 프로토콜이 정당한 세 경우

//   ① 구현이 실제로 여럿이다
protocol PaymentGateway: Sendable {
    func charge(_ amount: Decimal) async throws -> Receipt
}
struct StripeGateway: PaymentGateway {
    func charge(_ amount: Decimal) async throws -> Receipt { Receipt() }
}
struct TossGateway: PaymentGateway {
    func charge(_ amount: Decimal) async throws -> Receipt { Receipt() }
}

//   ② 테스트에서 반드시 대체해야 한다 (네트워크·시계·파일·난수처럼 통제 불가한 것)
protocol OrderRepository: Sendable {
    func save(_ order: Order) async throws
}
// non-mutating 요구사항이라 struct로는 기록할 수 없다 — actor로 둔다
actor SpyOrderRepository: OrderRepository {
    private(set) var saved: [Order] = []
    func save(_ order: Order) async throws { }
}

//   ③ 모듈 경계에서 의존 방향을 뒤집어야 한다 (DIP)

// ✅ 순수 함수는 프로토콜 없이도 완벽히 테스트된다 — 대체할 게 없기 때문이다
func test_트림() {
    assert(StringUtil.trim("  a  ") == "a")     // 목도 주입도 필요 없다
}

// 판별: "지금 이 프로토콜의 구현체를 둘 이상 만들 수 있는가?
//        테스트에서 대체해야 하는가?" — 둘 다 아니면 구체 타입.

struct Receipt {}; struct Order {}

import Foundation

// 좋은 추상화는 '변화 축'을 감춘다. 변하지 않는 것을 감추면 손해만 남는다.

// ❌ 변하지 않는 것을 감춘 추상화
protocol StringReversing {
    func reverse(_ s: String) -> String
}
struct DefaultStringReverser: StringReversing {
    func reverse(_ s: String) -> String { String(s.reversed()) }
}
// 문자열 뒤집기는 앞으로도 바뀌지 않는다.
// 얻는 것: 없음.  잃는 것: 파일·점프·프로토콜 준수 확인 비용.

// ✅ 실제로 변하는 축을 감춘 추상화
protocol PaymentGateway {
    func charge(_ amount: Decimal) async throws -> Receipt
}
// 결제사는 실제로 바뀐다 (Stripe → Toss → 자체 PG)
// 국가별로 다르고, A/B 테스트도 한다 → 변화 축이 명확하다

// ✅ 판별 질문 셋
//   ① 이 추상화의 구현체가 지금 둘 이상인가?
//   ② 앞으로 1년 안에 바뀔 구체적 계획이 있는가?
//   ③ 테스트에서 반드시 대체해야 하는가? (네트워크·시계·파일·난수)
//   → 셋 다 아니오면 구체 타입이 맞다

// ✅ 변화 축을 찾는 실전 방법: git 히스토리를 본다
//    git log --follow --oneline Sources/Payment/
//    → 자주 바뀌는 곳이 진짜 변화 축이다

// ⚠️ "혹시 나중에 필요할까 봐"는 변화 축의 근거가 아니다.
//    실제로 필요해졌을 때 뽑는 비용이, 지금 잘못 뽑는 비용보다 훨씬 싸다.

struct Receipt {}

import Foundation

// 파라미터가 계속 늘어나는 것은 "추상화가 틀렸다"는 가장 확실한 신호다.

// ❌ 처음엔 깔끔했던 함수가 이렇게 변해 간다
func renderBad(_ item: Item,
               compact: Bool = false,
               showsBadge: Bool = true,
               legacyLayout: Bool = false,
               isHighlighted: Bool = false,
               forExport: Bool = false) -> View {
    // 내부는 if의 미로가 되어 있다
    View()
}
// 조합 2⁵ = 32가지. 그중 실제로 쓰는 건 4가지쯤이고,
// 어떤 조합이 유효한지 아무도 모른다.

// ✅ ① 먼저 호출부에 인라인해 되돌린다
//    각 호출부가 실제로 무엇을 하는지 드러난다
func renderCompactRow(_ item: Item) -> View { View() }
func renderDetailHeader(_ item: Item) -> View { View() }
func renderExportCell(_ item: Item) -> View { View() }

// ✅ ② 되돌리고 나서 보면 진짜 축이 보인다
//    "compact/legacy/export"는 플래그가 아니라 '서로 다른 렌더러'였다
protocol ItemRenderer {
    func render(_ item: Item) -> View
}
struct CompactRenderer: ItemRenderer { func render(_ item: Item) -> View { View() } }
struct DetailRenderer: ItemRenderer { func render(_ item: Item) -> View { View() } }
struct ExportRenderer: ItemRenderer { func render(_ item: Item) -> View { View() } }

// ⚠️ 되돌리기가 두려워 플래그를 계속 덧대면 부채가 복리로 쌓인다.
//    인라인 → 관찰 → 재추출은 정상적인 리팩터링 사이클이다.

// ✅ 되돌리기를 안전하게 하는 조건: 테스트가 있어야 한다
//    테스트가 동작을 고정해 주면 구조를 자유롭게 바꿀 수 있다

// ⚠️ 경계는 적게·안정적으로 둔다.
//    얕고 넓게 여러 겹을 쌓는 것보다, 잘 고른 경계 하나가 낫다.

struct Item {}; struct View {}

import Foundation
import Combine

// 레이어를 늘릴수록 한 변경이 지나가야 하는 관문이 늘어난다.

// ❌ 과도한 레이어링 — 필드 하나 추가에 파일 6개를 고쳐야 한다
//    ViewController → Presenter → Interactor → UseCase
//                   → Repository → DataSource → APIClient
//    각 층마다 DTO 변환이 있으면 그것도 6번이다

// ✅ 경계는 '변경 이유가 다른 곳'에만 둔다
//    실무에서 대부분의 앱에 필요한 경계는 셋 정도다:

//   ① UI ↔ 상태
@MainActor
final class FeedViewModel: ObservableObject {
    @Published private(set) var state: LoadState = .idle
    private let repository: FeedRepository

    init(repository: FeedRepository) { self.repository = repository }

    func load() async {
        state = .loading
        do { state = .loaded(try await repository.items()) }
        catch { state = .failed(error.localizedDescription) }
    }
}

//   ② 상태 ↔ 데이터 (여기서 네트워크·DB가 감춰진다)
protocol FeedRepository: Sendable {
    func items() async throws -> [Item]
}

//   ③ 순수 계산 (경계가 아니라 그냥 함수)
enum FeedRules {
    static func visible(_ items: [Item], blocked: Set<String>) -> [Item] {
        items.filter { !blocked.contains($0.authorID) }
    }
}

// ✅ 구현
struct RemoteFeedRepository: FeedRepository {
    let client: APIClient
    func items() async throws -> [Item] { try await client.get("/feed") }
}

// ⚠️ "Clean Architecture니까 레이어가 많아야 한다"는 오해다.
//    그 책의 목적도 레이어 개수가 아니라 '변경 이유가 다른 것의 분리'다.
//    레이어가 변경 이유를 나누지 못하면 그건 clean이 아니라 잡음이다.

// ✅ 판별: "이 층을 없애면 무엇이 어려워지는가?"
//    답이 안 나오면 없애도 된다.

enum LoadState { case idle, loading, loaded([Item]), failed(String) }
struct Item: Sendable, Decodable { let authorID: String }
struct APIClient: Sendable {
    func get<T: Decodable>(_ path: String) async throws -> T {
        fatalError("예시")
    }
}