Visitor Pattern in iOS (Swift)

Visitor Pattern in Swift

Design Pattern Visitor 的實際應用場景分析

$Photo by [Daniel McCullough](https://unsplash.com/@d_mccullough?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText){:target="_blank"}$

Photo by Daniel McCullough

前言

「Design Pattern」從知道有這個東西到現在也超過 10 年了依然沒辦法有自信的說能完全掌握，一直以來都是矇矇懂懂的，也好幾次從頭到尾把所有模式都看過一遍，但看了沒內化、沒在實務上應用很快就忘了。

我真的廢。

內功與招式

曾經看到的一個很好的比喻，招式部分如：PHP、Laravel、iOS、Swift、SwiftUI…之類的應用，其實在其中切換學習門檻都不算高；但內功部分如：演算法、資料結構、設計模式…等等都屬於內功；內功與招式之間有著相輔相成的效果；但是招式好學，內功難練；招式厲害的內功不一定厲害，內功厲害的也可以很快學會招式，所以與其說相輔相成不如說內功才是基礎，搭配招式才能所向披靡。

找到適合自己的學習方式

基於之前的學習經驗，我認為適合我自己的學習 Design Pattern 方式是 — 先精再通；先著重於精通幾個模式，要能內化跟靈活運用，還要培養出嗅覺，能判斷什麼場景適合什麼場景不適合；再一步一步的累積新模式，直到全部掌握；我覺得最好的方式就是多找實務場境，從應用中學習。

學習資源

推薦兩個免費的學習資源

https://refactoringguru.cn/ ：完整介紹所有模式結構、場景、相互關係
https://shirazian.wordpress.com/2016/04/11/design-patterns-in-swift/ ：作者以實際開發 iOS 的場景介紹更個模式的應用，本文也會以這個方向撰寫

Visitor — Behavioral Patterns

第一章紀錄的是 Visitor Pattern，這也是在街聲工作一年挖到的金礦之一，在 StreetVoice App 中有諸多善用 Visitor 解決架構問題的地方；我也在這段經歷之中席的了 Visitor 的原理精髓；所以第一章就來寫它！

Visitor 是什麼

首先請先了解 Visitor 是什麼？想要解決什麼問題？組成結構是什麼？

$圖片取自 [refactoringguru](https://refactoringguru.cn/design-patterns/visitor){:target="_blank"}$

圖片取自 refactoringguru

詳細內容這邊不再重複贅述，請先直接參考 refactoringguru 對於 Visitor 的講解。

iOS 實務場景(一)

假設今天我們有以下幾個 Model：UserModel、SongModel、PlaylistModel 這三個 Model，現在我們要實作分享功能，可以分享到：Facebook、Line、Instagram，這三個平台；每個 Model 需要呈現的分享訊息皆為不同、每個平台需要的資料也各有不同：

組合場景如上圖，第一個表格顯示各 Model 的客製化內容、第二個表格顯示各分享平台需要的資料。

尤其 Instagram 在分享 Playlist 時要多張圖片，跟其他分享要的 source 不一樣。

定義 Model

首先把各個 Model 有哪些 Property 定義完成：

  
// Model
struct UserModel {
    let id: String
    let name: String
    let profileImageURLString: String
}

struct SongModel {
    let id: String
    let name: String
    let user: UserModel
    let coverImageURLString: String
}

struct PlaylistModel {
    let id: String
    let name: String
    let user: UserModel
    let songs: [SongModel]
    let coverImageURLString: String
}

// Data

let user = UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png")

let song = SongModel(id: "1",
                     name: "Wake me up",
                     user: user,
                     coverImageURLString: "https://zhgchg.li/cover/1.png")

let playlist = PlaylistModel(id: "1",
                            name: "Avicii Tribute Concert",
                            user: user,
                            songs: [
                                song,
                                SongModel(id: "2", name: "Waiting for love", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/3.png"),
                                SongModel(id: "3", name: "Lonely Together", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/1.png"),
                                SongModel(id: "4", name: "Heaven", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/4.png"),
                                SongModel(id: "5", name: "S.O.S", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/5.png")],
                            coverImageURLString: "https://zhgchg.li/playlist/1.png")

什麼都沒想的做法

完全不考慮架構，先上一個什麼都沒想的最髒做法。

周星馳 — 食神

  
class ShareManager {
    private let title: String
    private let urlString: String
    private let imageURLStrings: [String]

    init(user: UserModel) {
        self.title = "Hi 跟你分享一位很讚的藝人\(user.name)。"
        self.urlString = "https://zhgchg.li/user/\(user.id)"
        self.imageURLStrings = [user.profileImageURLString]
    }

    init(song: SongModel) {
        self.title = "Hi 與你分享剛剛聽到一首很讚的歌，\(song.user.name) 的 \(song.name)。"
        self.urlString = "https://zhgchg.li/user/\(song.user.id)/song/\(song.id)"
        self.imageURLStrings = [song.coverImageURLString]
    }

    init(playlist: PlaylistModel) {
        self.title = "Hi 這個歌單我聽個不停 \(playlist.name)。"
        self.urlString = "https://zhgchg.li/user/\(playlist.user.id)/playlist/\(playlist.id)"
        self.imageURLStrings = playlist.songs.map({ $0.coverImageURLString })
    }

    func shareToFacebook() {
        // call Facebook share sdk...
        print("Share to Facebook...")
        print("[![\(self.title)](\(String(describing: self.imageURLStrings.first))](\(self.urlString))")
    }

    func shareToInstagram() {
        // call Instagram share sdk...
        print("Share to Instagram...")
        print(self.imageURLStrings.joined(separator: ","))
    }

    func shareToLine() {
        // call Line share sdk...
        print("Share to Line...")
        print("[\(self.title)](\(self.urlString))")
    }
}

沒啥好說的，就是 0 架構全攪和在一起，如果今天要新加一個分享平台、更改某個平台的分享資訊、增加一個可分享的 Model 都要動到 ShareManager；另外 imageURLStrings 的設計因是考量到 Instagram 在分享歌單時需要圖片組資料所以才宣告成陣列，這有點倒因為果變成照需求去設計架構，其他不需要圖片組的類型也遭到污染。

優化一下

稍微分離一下邏輯。

  
protocol Shareable {
    func getShareText() -> String
    func getShareURLString() -> String
    func getShareImageURLStrings() -> [String]
}

extension UserModel: Shareable {
    func getShareText() -> String {
        return "Hi 跟你分享一位很讚的藝人\(self.name)。"
    }

    func getShareURLString() -> String {
        return "https://zhgchg.li/user/\(self.id)"
    }

    func getShareImageURLStrings() -> [String] {
        return [self.profileImageURLString]
    }
}

extension SongModel: Shareable {
    func getShareText() -> String {
        return "Hi 與你分享剛剛聽到一首很讚的歌，\(self.user.name) 的 \(self.name)。"
    }

    func getShareURLString() -> String {
        return "https://zhgchg.li/user/\(self.user.id)/song/\(self.id)"
    }

    func getShareImageURLStrings() -> [String] {
        return [self.coverImageURLString]
    }
}

extension PlaylistModel: Shareable {
    func getShareText() -> String {
        return "Hi 這個歌單我聽個不停 \(self.name)。"
    }

    func getShareURLString() -> String {
        return "https://zhgchg.li/user/\(self.user.id)/playlist/\(self.id)"
    }

    func getShareImageURLStrings() -> [String] {
        return [self.coverImageURLString]
    }
}

protocol ShareManagerProtocol {
    var model: Shareable { get }
    init(model: Shareable)
    func share()
}

class FacebookShare: ShareManagerProtocol {
    let model: Shareable

    required init(model: Shareable) {
        self.model = model
    }

    func share() {
        // call Facebook share sdk...
        print("Share to Facebook...")
        print("[![\(model.getShareText())](\(String(describing: model.getShareImageURLStrings().first))](\(model.getShareURLString())")
    }
}

class InstagramShare: ShareManagerProtocol {
    let model: Shareable

    required init(model: Shareable) {
        self.model = model
    }

    func share() {
        // call Instagram share sdk...
        print("Share to Instagram...")
        print(model.getShareImageURLStrings().joined(separator: ","))
    }
}

class LineShare: ShareManagerProtocol {
    let model: Shareable

    required init(model: Shareable) {
        self.model = model
    }

    func share() {
        // call Line share sdk...
        print("Share to Line...")
        print("[\(model.getShareText())](\(model.getShareURLString())")
    }
}

我們抽離出一個 CanShare Protocol，凡是 Model 有遵循這個協議都能支援分享；分享的部分也抽離出 ShareManagerProtocol，有新的分享只要實現協議內容即可、要修改刪除也都不會影響其他 ShareManager。

但 getShareImageURLStrings 依然詭異，另外假設今天新增的分享平台需求的 Model 資料天壤之別，例如微信分享還需要播放次數、創建日期…等資訊，只有他要，這時候就會開始變得混亂。

Visitor

使用 Visitor Pattern 的解法。

  
// Visitor Version
protocol Shareable {
    func accept(visitor: SharePolicy)
}

extension UserModel: Shareable {
    func accept(visitor: SharePolicy) {
        visitor.visit(model: self)
    }
}

extension SongModel: Shareable {
    func accept(visitor: SharePolicy) {
        visitor.visit(model: self)
    }
}

extension PlaylistModel: Shareable {
    func accept(visitor: SharePolicy) {
        visitor.visit(model: self)
    }
}

protocol SharePolicy {
    func visit(model: UserModel)
    func visit(model: SongModel)
    func visit(model: PlaylistModel)
}

class ShareToFacebookVisitor: SharePolicy {
    func visit(model: UserModel) {
        // call Facebook share sdk...
        print("Share to Facebook...")
        print("[![Hi 跟你分享一位很讚的藝人\(model.name)。](\(model.profileImageURLString)](https://zhgchg.li/user/\(model.id)")
    }
    
    func visit(model: SongModel) {
        // call Facebook share sdk...
        print("Share to Facebook...")
        print("[![Hi 與你分享剛剛聽到一首很讚的歌，\(model.user.name) 的 \(model.name)，他被播方式。](\(model.coverImageURLString))](https://zhgchg.li/user/\(model.user.id)/song/\(model.id)")
    }
    
    func visit(model: PlaylistModel) {
        // call Facebook share sdk...
        print("Share to Facebook...")
        print("[![Hi 這個歌單我聽個不停 \(model.name)。](\(model.coverImageURLString))](https://zhgchg.li/user/\(model.user.id)/playlist/\(model.id)")
    }
}

class ShareToLineVisitor: SharePolicy {
    func visit(model: UserModel) {
        // call Line share sdk...
        print("Share to Line...")
        print("[Hi 跟你分享一位很讚的藝人\(model.name)。](https://zhgchg.li/user/\(model.id)")
    }
    
    func visit(model: SongModel) {
        // call Line share sdk...
        print("Share to Line...")
        print("[Hi 與你分享剛剛聽到一首很讚的歌，\(model.user.name) 的 \(model.name)，他被播方式。]](https://zhgchg.li/user/\(model.user.id)/song/\(model.id)")
    }
    
    func visit(model: PlaylistModel) {
        // call Line share sdk...
        print("Share to Line...")
        print("[Hi 這個歌單我聽個不停 \(model.name)。](https://zhgchg.li/user/\(model.user.id)/playlist/\(model.id)")
    }
}

class ShareToInstagramVisitor: SharePolicy {
    func visit(model: UserModel) {
        // call Instagram share sdk...
        print("Share to Instagram...")
        print(model.profileImageURLString)
    }
    
    func visit(model: SongModel) {
        // call Instagram share sdk...
        print("Share to Instagram...")
        print(model.coverImageURLString)
    }
    
    func visit(model: PlaylistModel) {
        // call Instagram share sdk...
        print("Share to Instagram...")
        print(model.songs.map({ $0.coverImageURLString }).joined(separator: ","))
    }
}

// Use case
let shareToInstagramVisitor = ShareToInstagramVisitor()
user.accept(visitor: shareToInstagramVisitor)
playlist.accept(visitor: shareToInstagramVisitor)

我們逐行來看做了什麼：

首先我們創建了一個 Shareable 的 Protocol，其目的只是方便我們管理 Model 支援分享 Visitor 有統一的接口 (不定義也行)。
UserModel/SongModel/PlaylistModel 實現 Shareable func accept(visitor: SharePolicy) ，之後如果有新增支援分享的 Model 也只需實現協議
定義出 SharePolicy 列出所支援的 Model (must be concrete type) 或許你會想為何不定義成 visit(model: Shareable) 如果是這樣就重蹈上一版的問題了
各個 Share 方法實現 SharePolicy，各自依照 source 去組合需要的資源
假設今天多一個微信分享，他要的資料比較特別(播放次數、創建日期)，也不會影響現有程式碼，因為他能從 concrete model 拿到他自己需要的資訊。

達成低耦合、高聚合的程式開發目標。

以上是經典的 Visitor Double Dispatch 實現，但我們日常開發上比較少會遇到這種狀況，一般常見的狀況可能只會有一個 Visitor，但我覺得也很適合使用這套模式組合，例如今天有一個 SaveToCoreData 的需求，我們也可以直接定義 accept(visitor: SaveToCoreDataVisitor) ，不多宣告出 Policy Protocol，也是個很好的使用架構。

  
protocol Saveable {
  func accept(visitor: SaveToCoreDataVisitor)
}

class SaveToCoreDataVisitor {
    func visit(model: UserModel) {
        // map UserModel to coredata
    }
    
    func visit(model: SongModel) {
        // map SongModel to coredata
    }
    
    func visit(model: PlaylistModel) {
        // map PlaylistModel to coredata
    }
}

其他應用：Save、Like、tableview/collectionview cellforrow….

原則

最後講一下一些共通原則

Code 是給人讀的，切勿 Over Designed
統一很重要，同樣的場境同個 Codebase 應該使用同個架構方法
如果範圍是可控的或不可能出現其他狀況，這時候如果還繼續往下拆分就可以認為是 Over Designed
多應用、少發明；Design Pattern 已經在軟體設計領域好幾十年，他所考量到的場景一定比我們創造一個新的架構還來的完善
看不懂 Design Pattern 可以學，但如果是自己創造的架構就比較難說服別人學，因為學了可能也只能用在這個 Case 上，他就不是一個 Common sense
程式碼重複不代表不好，如果一昧追求封裝可能導致 Over Designed；一樣回到前面幾點，程式是給人讀的，所以只要是好讀加上低耦合高聚合都是好的 Code
勿魔改 Pattern，人家設計一定有他的道理，如果亂魔改可能導致某些場景出現問題
只要開始繞路就會越繞越遠，程式會越來越髒

inspired by ＠saiday

===

本文首次發表於 Medium ➡️ 前往查看