Swift中Transferable协议transferRepresentation的条件化实现问题

方案一：通过类型标记+MultipleRepresentation实现条件化导出 #

不需要拆分类，给Media新增一个媒体类型标记属性，然后在transferRepresentation里用MultipleRepresentation组合不同类型的导出逻辑，每个导出分支根据实例的类型判断是否执行。

修改后的代码： #

import Foundation
import SwiftUI
import UniformTypeIdentifiers

// 定义媒体类型枚举
enum MediaType: Codable {
    case audio, image, video
}

@Model
class Media: Transferable {
    @Attribute(.externalStorage) var file: Data? = nil    
    var url: String? = nil
    var mediaType: MediaType // 新增：标记当前媒体的类型
    
    public static var transferRepresentation: some TransferRepresentation {
        MultipleRepresentation {
            // 音频导出逻辑
            FileRepresentation(exportedContentType: .wav) { media in
                guard media.mediaType == .audio, 
                      let urlStr = media.url, 
                      let fileURL = URL(string: "\(AudioHelper.getDocumentsDirectory())\(urlStr)") else {
                    throw TransferError.unsupportedContentType
                }
                return SentTransferredFile(fileURL)
            }
            
            // 图片导出逻辑（支持Data或URL两种存储方式）
            FileRepresentation(exportedContentType: .png) { media in
                guard media.mediaType == .image else {
                    throw TransferError.unsupportedContentType
                }
                
                if let imageData = media.file {
                    // 将Data写入临时文件返回，分享后自动删除
                    let tempURL = FileManager.default.temporaryDirectory.appendingPathComponent("temp_image_\(UUID()).png")
                    try imageData.write(to: tempURL)
                    return SentTransferredFile(tempURL, shouldRemove: true)
                } else if let urlStr = media.url, 
                          let fileURL = URL(string: "\(AudioHelper.getDocumentsDirectory())\(urlStr)") {
                    return SentTransferredFile(fileURL)
                } else {
                    throw TransferError.noValidSource
                }
            }
            
            // 后续新增视频类型时，直接添加对应的FileRepresentation即可
        }
    }
    
    // 自定义错误类型，用于处理导出失败场景
    enum TransferError: Error {
        case unsupportedContentType
        case noValidSource
    }
}

方案优缺点： #

• ✅ 无需重构现有类结构，快速适配多类型需求
• ❌ 随着媒体类型增多，transferRepresentation会逐渐臃肿，逻辑耦合度高，后期维护成本上升

方案二：拆分子类，利用多态实现各自的Transferable逻辑 #

将通用的Media作为基类，为每种媒体类型创建独立子类，各自实现专属的transferRepresentation，更符合面向对象的单一职责原则。

修改后的代码： #

import Foundation
import SwiftUI
import UniformTypeIdentifiers

// 基类：只包含通用属性和方法，不实现Transferable
@Model
class Media {
    @Attribute(.externalStorage) var file: Data? = nil    
    var url: String? = nil
    
    // 这里可以添加所有媒体类型通用的方法
}

// 音频子类：实现Transferable，专注音频分享逻辑
@Model
class AudioMedia: Media, Transferable {
    public static var transferRepresentation: some TransferRepresentation {
        FileRepresentation(exportedContentType: .wav) { audio in
            guard let urlStr = audio.url, 
                  let fileURL = URL(string: "\(AudioHelper.getDocumentsDirectory())\(urlStr)") else {
                throw TransferError.invalidAudioURL
            }
            return SentTransferredFile(fileURL)
        }
    }
    
    enum TransferError: Error {
        case invalidAudioURL
    }
}

// 图片子类：实现Transferable，专注图片分享逻辑
@Model
class ImageMedia: Media, Transferable {
    public static var transferRepresentation: some TransferRepresentation {
        FileRepresentation(exportedContentType: .png) { image in
            if let imageData = image.file {
                let tempURL = FileManager.default.temporaryDirectory.appendingPathComponent("temp_image_\(UUID()).png")
                try imageData.write(to: tempURL)
                return SentTransferredFile(tempURL, shouldRemove: true)
            } else if let urlStr = image.url, 
                      let fileURL = URL(string: "\(AudioHelper.getDocumentsDirectory())\(urlStr)") {
                return SentTransferredFile(fileURL)
            } else {
                throw TransferError.noImageSource
            }
        }
    }
    
    enum TransferError: Error {
        case noImageSource
    }
}

// 后续新增视频类型时，只需创建VideoMedia子类并实现Transferable即可

方案优缺点： #

• ✅ 职责单一，每个子类只处理对应媒体类型的逻辑，扩展性强，后期维护方便
• ❌ 需要重构现有代码，迁移原有的Media实例到对应子类，初期有一定工作量

选择建议 #

• 如果当前仅需支持2-3种媒体类型，且短期内没有扩展计划，优先选方案一快速解决问题
• 如果后续需要持续新增媒体类型（如视频），推荐选方案二，长期来看代码结构更健壮、易维护

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