在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
别人一看到我的 Swift 代码,立刻就会问我为什么如此频繁的使用 extension。这是前几天在我写的另一篇文章中收到的评论: 我大量使用 extension 的主要目的是为了提高代码可读性。以下是我喜欢使用 extension 的场景,尽管 extension 并非是为这些场景设计的。 私有的辅助函数在 Objective-C 中,我们有 .h 文件和 .m 文件。同时管理这两个文件(以及在工程中有双倍的文件)是一件很麻烦的事情,好在我们只要快速浏览 .h 文件就可以知道这个类对外暴露的 API,而内部的信息则被保存在 .m 文件中。在 Swift 中,我们只有一个文件。 为了一眼就看出一个 Swift 类的公开方法(可以被外部访问的方法),我把内部实现都写在一个私有的 extension 中,比如这样:
注意,在上面这个例子中,属性字符串的计算逻辑非常复杂。如果把它写在结构体的主体部分中,我就无法一眼看出这个结构体中哪个部分是重要的(也就是 Objective-C 中写在 .h 文件中的代码)。在这个例子中,使用 extension 使我的代码结构变得更加清晰整洁。 这样一个很长的 extension 也为日后重构代码打下了良好的基础。我们有可能把这段逻辑抽取到一个单独的结构体中,尤其是当这个属性字符串可能在别的地方被用到时。但在编程时把这段代码放在私有的 extension 里面是一个良好的开始。 分组我最初开始使用 extension 的真正原因是在 Swift 刚诞生时,无法使用 pragma 标记(译注:Objective-C 中的 #pragma mark)。是的,这就是我在 Swift 刚诞生时想做的第一件事。我使用 pragma 来分割 Objective-C 代码,所以当我开始写 Swift 代码时,我需要它。 所以我在 WWDC Swift 实验室时询问苹果工程师如何在 Swift 中使用 pragma 标记。和我交流的那位工程师建议我使用 extension 来替代 pragma 标记。于是我就开始这么做了,并且立刻爱上了使用 extension。 尽管 pragma 标记(Swift 中的 //MARK)很好用,但我们很容易忘记给一段新的代码加上 MARK 标记,尤其是你处在一个具有不同代码风格的小组中时。这往往会导致若干个无关函数被放在了同一个组中,或者某个函数处于错误的位置。所以如果有一组函数应该写在一起,我倾向于把他们放到一个 extension 中。 一般我会用一个 extension 存放 ViewController 或者 AppDelegate 中所有初始化 UI 的函数,比如:
或者把所有和通知相关的逻辑放到一起:
遵守协议这是一种特殊的分组,我会把所有用来实现某个协议的方法放到一个 extension 中。在 Objective-C 中,我习惯使用 pragma 标记。不过我喜欢 extension 更加彻底的分割和更好的可读性:
这种方法同样非常适用于分割 UITableViewDataSource 和 UITableViewDelegate 的代码:
模型(Model)这是一种我在使用 Objective-C 操作 Core Data 时就喜欢采用的方法。由于模型发生变化时,Xcode 会生成相应的模型,所以函数和其他的东西都是写在 extension 或者 category 里面的。 在 Swift 中,我尽可能多的尝试使用结构体,但我依然喜欢使用 extension 将 Model 的属性和基于属性的计算分割开来。这使 Model 的代码更容易阅读:
长话短说(TL;DR)尽管这些用法可能不那么“传统”,但 Swift 中 extension 的简单使用,可以让代码质量更高,更具可读性。
转载自:http://swift.gg/2016/05/16/using-swift-extensions/ 参考链接:https://www.natashatherobot.com/using-swift-extensions/ |
请发表评论