如何高效存储并访问数百个带关联值的枚举？

Great question! When dealing with enums that have hundreds of cases with associated values, linear switch-based searches can become both a performance bottleneck (O(n) time complexity for every access) and a maintenance nightmare (duplicating switch logic across multiple accessor functions). Let’s break down practical, optimized solutions tailored to your scenario:

Option 1: Tag Enum + Static Metadata Array (Balanced Type Safety & Efficiency) #

This is my go-to solution—it retains the type safety of native enums while enabling O(1) metadata access, and eliminates redundant switch code.

Step-by-Step Implementation: #

1. Define a private tag enum that maps 1:1 to your public enum’s cases, with an auto-synthesized Int raw value:

private enum FooTag: Int {
    case A, B, C // Match the exact order of your Foo enum cases
    // ... add all 100+ cases here
}

2. Create a metadata struct to hold all values your accessor functions need to return:

private struct FooMetadata {
    let number: Int
    let displayName: String
    let isActive: Bool
    // Add any other properties your accessors need
}

3. Build a static metadata array, ordered to match your FooTag cases:

extension Foo {
    private static let metadataStore: [FooMetadata] = [
        FooMetadata(number: 10, displayName: "Case A", isActive: true),
        FooMetadata(number: 20, displayName: "Case B", isActive: false),
        // ... add a metadata entry for every FooTag case
    ]
}

4. Update your public enum to include the FooTag as the first associated value for every case:

public enum Foo {
    case A(tag: FooTag, String, Int)
    case B(tag: FooTag, Double, Bool)
    // ... all cases now include the tag
}

5. Implement a single metadata fetcher (only one switch to write!) and reuse it for all accessors:

extension Foo {
    private func getMetadata() -> FooMetadata {
        switch self {
        case .A(let tag, _, _):
            return Self.metadataStore[tag.rawValue]
        case .B(let tag, _, _):
            return Self.metadataStore[tag.rawValue]
        // ... add one case branch for each Foo case (one-time work)
        }
    }

    // Your accessor functions now become trivial
    func getNumber() -> Int {
        getMetadata().number
    }

    func getDisplayName() -> String {
        getMetadata().displayName
    }

    func isActive() -> Bool {
        getMetadata().isActive
    }
}

Pros:

• O(1) metadata access (far faster than linear switch searches for 100+ cases)
• Full type safety—compiler catches mismatched tags or metadata entries
• Minimal code duplication: all accessors reuse the same getMetadata() logic
• Easy to maintain: adding a new case only requires updating the tag enum, metadata array, and one switch branch

Option 2: Reflection + Metadata Array (Minimal Code, Fast Iteration) #

If writing 100+ switch branches feels tedious, you can use Swift’s reflection API to extract the tag automatically. This trades a tiny bit of type safety for drastically less code.

Implementation: #

Follow steps 1-4 from Option 1, then replace getMetadata() with a reflection-based tag fetcher:

extension Foo {
    private func getTag() -> FooTag {
        let mirror = Mirror(reflecting: self)
        guard let firstAssocValue = mirror.children.first?.value else {
            fatalError("Foo case missing expected associated values")
        }
        guard let tag = firstAssocValue as? FooTag else {
            fatalError("Foo case's first associated value must be a FooTag")
        }
        return tag
    }

    func getNumber() -> Int {
        Self.metadataStore[getTag().rawValue].number
    }
}

Pros:

• No need to write 100+ switch branches—code stays concise
• Still O(1) access (reflection overhead is negligible compared to linear searches)
• Adding new cases only requires updating the tag enum and metadata array

Cons:

• Relies on your enum’s case structure (first associated value must be FooTag)—breaking this will cause runtime crashes (add clear code comments to avoid this)
• Slightly less type safety than Option 1

Option 3: Struct + Tag Enum (Ultimate Performance) #

If your enum is accessed extremely frequently (e.g., in tight loops), you can refactor it into a struct with a tag enum. This eliminates all switch and reflection overhead for maximum performance.

Implementation: #

1. Define a public tag enum:

public enum FooTag: Int {
    case A, B, C
    // ... all cases
}

2. Create metadata and associated value structs:

private struct FooMetadata {
    let number: Int
    let displayName: String
}

private static let metadataStore: [FooMetadata] = [
    // ... entries matching FooTag order
]

public struct AAssociatedValues {
    let str: String
    let num: Int
}

public struct BAssociatedValues {
    let doubleVal: Double
    let flag: Bool
}

3. Build the Foo struct with type-safe convenience initializers:

public struct Foo {
    public let tag: FooTag
    private let associatedValues: Any

    // Convenience initializers hide the underlying Any type
    public static func a(_ str: String, _ num: Int) -> Foo {
        Foo(tag: .A, associatedValues: AAssociatedValues(str: str, num: num))
    }

    public static func b(_ doubleVal: Double, _ flag: Bool) -> Foo {
        Foo(tag: .B, associatedValues: BAssociatedValues(doubleVal: doubleVal, flag: flag))
    }

    // Type-safe associated value accessors
    public func getAAssociatedValues() -> AAssociatedValues? {
        guard tag == .A else { return nil }
        return associatedValues as? AAssociatedValues
    }

    // Metadata accessors are pure O(1) array lookups
    public func getNumber() -> Int {
        metadataStore[tag.rawValue].number
    }
}

Pros:

• Zero switch or reflection overhead—fastest possible access
• Clean separation of metadata and associated values

Cons:

• Loses native enum features (e.g., compiler-enforced switch exhaustiveness checks)
• Associated value access requires optional binding, which is less intuitive than enum switch matching

Why Your Original Switch Approach Is Suboptimal #

Linear switch searches have O(n) time complexity—for 100+ cases, every accessor call has to iterate through dozens of branches before finding a match. Multiply that across multiple accessor functions and frequent calls, and you’ll see measurable performance hits. Plus, duplicating switch logic across functions makes it easy to miss cases when adding new enum members, leading to bugs.

Choose the option that best fits your priorities: type safety (Option 1), minimal code (Option 2), or maximum performance (Option 3).

内容的提问来源于stack exchange，提问作者Matt