通过Notification.Name看Swift是如何优雅的解决String硬编码

前面

初学 Swift 中相关 NSNotification 的代码时, 发现了之前熟悉的 name 参数的类型由 Objective-C 中的 NSString 变成了 Notification.Name 类型. 并不是我期望的 String 类型...这是怎么回事呢?

Swift 中如何使用 Notification

那么, 在 Swift 中如何使用 Notification 呢, 以 post 为例.

NotificationCenter.default.post(name: Notification.Name.UIApplicationDidFinishLaunching, object: nil)

其中, Notification.Name 是可以省略的, 就变为了

NotificationCenter.default.post(name: .UIApplicationDidFinishLaunching, object: nil)

查看定义发现了 UIApplicationDidFinishLaunching 实际上是定义在结构体 NSNotification.Name 扩展(extension)中的的一个静态常量 (static let), 类型是 NSNotification.Name

extension NSNotification.Name {

    @available(iOS 4.0, *)

    public static let UIApplicationDidEnterBackground: NSNotification.Name

    @available(iOS 4.0, *)

    public static let UIApplicationWillEnterForeground: NSNotification.Name

    public static let UIApplicationDidFinishLaunching: NSNotification.Name

    ...

}

复制代码所以我们才可以省略前面的 Notification.Name 直接使用 .UIApplicationDidFinishLaunching (Notification.Name 是 NSNotification.Name 的别名)

那我们如果想自定义一个通知怎么办呢, 直接可以仿照系统的方式, 我们自己为其增加一个 extension

extension Notification.Name {

    static let LoginStatusChanged = Notification.Name("LoginStatusChanged")

}

其中 Notification.Name("LoginStatusChanged") 是其初始化方法, 可查看文档说明, 使用时, 可直接

NotificationCenter.default.post(name: .LoginStatusChanged, object: nil)

因为这个通知 LoginStatusChanged 是定义在 Notification.Name 中的了, 所以也没必要在名称后面增加 Notification 等字样来表示这是一个通知了. 所以 Swift 中很多定义的名称都是非常简洁的.

对比 Objective-C 中的使用

对比之前在 Objective-C 中的使用

[[NSNotificationCenter defaultCenter] postNotificationName:"xxxxxxxxxx" object:nil

这样是非常容易出错的, 查这样的错误经常也是非常费时费力的, 也让人看来是非常不优雅的, 所以我们经常会进行宏定义或者是常量来防止字符串硬编码的问题.

但这实际上也是会带来一些令人头疼的问题的:

为了表明定义的字符串常量是一个通知名, 还要为其增加冗长的前缀或者是后缀

在开发中还经常会在代码补全中, 看到根本不和场合的一些常量名

通常为了使用方便和易于维护, 还会在将所有的通知定义在一个 xxDefine.h 的头文件中, 并在 pch 文件中引用, 此时如果增删或者修改了任意通知. 将会引起工程的全量重新编译. 也很是头疼.

...

所以, Swift 这种使用方式可谓是十分优雅.

举一反三

在开发中, 其实类似于 Notification 这种需要传递字符串的场景还有很多, 我们都可以使用这类使用方法进行优化.

场景

假设有这样一个场景, 定义一个类 EventReporter 用来处理埋点请求.

class EventReporter {

    static let shared = EventReporter()

    func reportEvent(_ eventId: String, withParams params: [String:Any]?) {

        // 埋点上报逻辑

    }

}

相信这样的场景是很多人都见过的, 其中 eventId 是我们埋点的事件的ID, 那么该如何使用类似 Notification.Name 的方式来优化这类场景呢?

原理

从文档中看出 Notification.Name 实际上是遵从了一个协议 RawRepresentable

Overview

With a RawRepresentable type, you can switch back and forth between a custom type and an associated RawValue type without losing the value of the original RawRepresentable type. Using the raw value of a conforming type streamlines interoperation with Objective-C and legacy APIs and simplifies conformance to other protocols, such as Equatable, Comparable, and Hashable.

The RawRepresentable protocol is seen mainly in two categories of types: enumerations with raw value types and option sets.

简单的说就是, 使用 RawRepresentable 类型, 可以在自定义类型和其关联的 RawValue 类型之间来回切换, 可简化与 Objective-C 和传统 API 的交互, 两类:具有原始值类型和选项集的枚举(OptionSet, 其实 Swift 中的选项集枚举就是集成自 RawRepresentable 这个 Protocol 实现的), 说白了. 就是用一个类型封装一下我们想要使用的类型比如说 String, 来方便交互.

实现

使用起来很简单, 定义一个结构体来管理所有的埋点事件

struct EventID: RawRepresentable {

}

根据编译器提示, 补全协议代码

struct EventID: RawRepresentable {

    typealias RawValue = String

    var rawValue: String

    init?(rawValue: String) {

    }

}

从这就更容易看出其原理, 实际上内部的 rawValue 属性就是我们需要使用的 String 类型的事件名, 初始化方法传入该 String 对其赋值即可, 返回 EventID 类型的结构体

这里发现初始化方法返回的是一个 Optional 类型, 这样使用起来还需要解包, 不太方便, 可以看到 Notification.Name 的初始化方法返回并不是 Optional, 因为定义都是非常确定的事件名(通知名), 而且 init 方法中也不会产生异常, 所以此处没什么必要使用 Optional, 去掉 ? 即可

struct EventID: RawRepresentable {

    typealias RawValue = String

    var rawValue: String

    init(rawValue: String) {

        self.rawValue = rawValue

    }

}

那么, 我们的上报类的代码可以修改如下, 这里还可以给 params 一个默认值, 这样如果没有参数时, 可以只传递 eventId 一个参数即可.

class EventReporter {

    static let shared = EventReporter()

    func reportEvent(_ eventId: EventID, withParams params: [String:Any]? = nil) {

    let event = eventId.rawValue

        // 埋点逻辑

    }

}

最后, 定义一个埋点事件看看吧~, 推荐写到 extension 中易于维护.

extension EventID {

static let LoginPageExposure = EventID(rawValue: "login_page_exposure")

}

那么使用的时候,

EventReporter.shared.reportEvent(.LoginPageExposure)

当我们打出 . 的时候, 代码补全就已经将 LoginPageExposure 提示给我们了.

总结

使用这种方式优化代码, 不仅可以让代码意图容易理解, 使用也更加简单不会出错. 而且也不会使得 LoginPageExposure 事件名在不想要出现的时候被代码补全功能强行弹出来.

参考文章

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,039评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,426评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,417评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,868评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,892评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,692评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,416评论 3 419
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,326评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,782评论 1 316
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,957评论 3 337
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,102评论 1 350
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,790评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,442评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,996评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,113评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,332评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,044评论 2 355

推荐阅读更多精彩内容