用 Swift 编写面向协议的网络请求 - 简书
用 Swift 编写面向协议的网络请求
作者：Natasha The Robot，，原文日期：译者：；校对：；定稿：
9 月 1 日 - 9月 2 日在纽约举办的 Swift 社区庆典?吧！使用优惠码 NATASHATHEROBOT 可以获得 $100 的折扣！
我最近做了个 Swift （POP?） 的演讲。视频还在处理中。另一方面，这是演讲中 POP 视图部分的文本记录，供我和其他任何人作参考！
普通的配置方式
假设我们要做一款展示全球美食图片和信息的 App。这需要从 API 上拉取数据，那么，用一个对象来做网络请求也就是理所当然的了：
struct FoodService {
func get(completionHandler: Result&[Food]& -& Void) {
// 异步网络请求
// 返回请求结果
一旦我们创建了异步请求，就不能使用 Swift 內建的错误处理来同时返回成功响应和请求错误了。不过，倒是给练习 Result 枚举创造了机会（更多关于 Result 枚举的信息可以参考 ），下面是一个最基础的 Result 写法：
enum Result&T& {
case Success(T)
case Failure(ErrorType)
当 API 请求成功，回调便会获得 Success 状态与能正确解析的数据 —— 在当前 FoodService 例子中，成功的状态包含着美食信息数组。如果请求失败，会返回 Failure 状态，并包含错误信息（如 400）。
FoodService 的 get 方法（发起 API 请求）通常会在 ViewController 中调用，ViewController 来决定请求成功失败后具体的操作逻辑：
// FoodLaLaViewController
var dataSource = [Food]() {
tableView.reloadData()
override func viewDidLoad() {
super.viewDidLoad()
private func getFood() {
// 在这里调用 get() 方法
FoodService().get() { [weak self] result in
switch result {
case .Success(let food):
self?.dataSource = food
case .Failure(let error):
self?.showError(error)
但，这样处理有个问题...
有什么问题
关于 ViewController 中 getFood() 方法的问题是：ViewController 太过依赖这个方法了。如果没有正确的发起 API 请求或者请求结果（无论 Success 还是 Failure）没有正确的处理，那么界面上就没有任何数据显示。
为了确保这个方法没问题，给它写测试显得尤为重要（如果实习生或者你自己以后一不小心改了什么，那界面上就啥都显示不出来了）。是的，View Controller Tests ?！
说实话，它没那么麻烦。这有一个来配置 View Controller 测试。
OK，现在已经准备好进行 View Controller 测试了，下一步要做什么？！
为了正确地测试 ViewController 中 getFood() 方法，我们需要注入 FoodService（依赖），而不是直接调用这个方法！
// FoodLaLaViewController
override func viewDidLoad() {
super.viewDidLoad()
// 传入默认的 food service
getFood(fromService: FoodService())
// FoodService 被注入
func getFood(fromService service: FoodService) {
service.get() { [weak self] result in
switch result {
case .Success(let food):
self?.dataSource = food
case .Failure(let error):
self?.showError(error)
下面的方法便可开始测试：
// FoodLaLaViewControllerTests
func testFetchFood() {
viewController.getFood(fromService: FoodService())
// ? 接下来?
接下来，我们需要对 FoodService 返回值类型进行更多的约束。
绝杀 —— 协议
目前 FoodService 的结构体是这样：
struct FoodService {
func get(completionHandler: Result&[Food]& -& Void) {
// 发起异步请求
// 返回请求结果
为了方便测试，我们需要能够重写 get 方法，来控制哪个 Result（Success 或 Failure）传给 ViewController，之后就可以测试 ViewController 是如何处理这两种结果。
因为 FoodService 是结构体类型，所以不能对其子类化。但是，你猜怎样，我们可以使用协议来达到重写目的。
我们可以将功能性代码单独提到一个协议中：
protocol Gettable {
associatedtype Data
func get(completionHandler: Result&Data& -& Void)
注意这里标明了引用类型（associated type）。这个协议将会用在所有的 service 结构体上，现在我们只让 FoodService 去遵循，但是以后还会有 CakeService 或者 DonutService 去遵循。通过使用这个通用性的协议，就可以在 App 中非常完美的统一所有 service 了。
现在，唯一需要改变的就是 FoodService —— 让它遵循 Gettable 协议：
struct FoodService: Gettable {
// [Food] 用于限制传入的引用类型
func get(completionHandler: Result&[Food]& -& Void) {
// 发起异步请求
// 返回请求结果
这样写还有一个好处 —— 良好的可读性。看到 FoodService 时，你会立刻注意到 Gettable 协议。你也可以创建类似的 Creatable，Updatable，Delectable，这样，service 能做的事情显而易见！
使用协议 ?
是时候重构一下了！在 ViewController 中，相比之前直接调用 FoodService 的 getFood 方法，我们现在可以将 Gettable 的引用类型限制为 [Food]。
// FoodLaLaViewController
override func viewDidLoad() {
super.viewDidLoad()
getFood(fromService: FoodService())
func getFood&Service: Gettable where Service.Data == [Food]&(fromService service: Service) {
service.get() { [weak self] result in
switch result {
case .Success(let food):
self?.dataSource = food
case .Failure(let error):
self?.showError(error)
现在，测试起来容易多了！
要测试 ViewController 的 getFood 方法，我们需要注入遵循 Gettable 并且引用类型为 [Food] 的 service：
// FoodLaLaViewControllerTests
class Fake_FoodService: Gettable {
var getWasCalled = false
// 你也可以在这里定义一个失败结果变量，用来测试失败状态
// food 变量是一个数组(在此仅为测试目的)
var result = Result.Success(food)
func get(completionHandler: Result&[Food]& -& Void) {
getWasCalled = true
completionHandler(result)
所以，我们可以注入 Fake_FoodService 来测试 ViewController 的确发起了请求，并正确的返回了 [Food] 类型的结果（定义为 [Food] 是因为 TableView 的 data source 所要用到的类型就是 [Food]）：
// FoodLaLaViewControllerTests
func testFetchFood_Success() {
let fakeFoodService = Fake_FoodService()
viewController.getFood(fromService: fakeFoodService)
XCTAssertTrue(fakeFoodService.getWasCalled)
XCTAssertEqual(viewController.dataSource.count, food.count)
XCTAssertEqual(viewController.dataSource, food)
现在你也可以仿照这个写法完成失败状态的测试（比如，根据收到的 ErrorType 显示对应的错误信息）。
使用协议来封装网络层，可以使代码统一、 可注入、 可测试、更可读。
POP 万岁！
本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 。
GitHub脑残粉 | OSI组织成员 | Python | JS | iOS | 译者 | 组织翻译了《The Swift Programming Language》Swift面向协议编程 - NSNirvana的博客 - CSDN博客
Swift面向协议编程
一、使用类的好处
3.采用命名空间来避免冲突
4.表意性极强的语句
5.可拓展性
在Swift中，前三点使用结构体和枚举就也完全可以实现。
二、在以往的面向对象编程中，只有类才能提供的
1.类的继承层次体系
2.类由于方法变量可重载所具有的可定制和重用性
在Swift中，可定制性用结构体也可实现。
三、类的使用代价
1.引用类型带来的隐式共享（implicit sharing）
为此，你有时需要不断的调用copy来给每个可变量（mutable）自己的值，而且会降低系统的运行效率，可能会导致死锁，使代码变得更加复杂，还会导致各种Bug。
以往collectionType的绝对分享性会导致的各种问题在Swift中不会出现，因为Swift中collectionType是值类型而不是引用类型，它们不分享。
2.你需要继承父类的一切
它太过臃肿，所有可能相关的都被一股脑丢了进去，而且你在一开始就必须决定好你的父类，而不是后期根据需求选择。
如果父类有存储类型的变量，你别无选择必须全部接受它们。而且要对它们进行初始化，还要注意不破坏父类的常量。
你需要选择是否和如何以可行的方式对父类方法进行重载。
3.类的抽象性导致类型之间的关系信息丢失（Lost Type Relationship）
你在什么信息都不了解的时候，还必须在最初的父类中一定会被重载方法里面放一些代码。
你需要用as! 对抽象的类型进行进一步的明确。
四、我们需要一种更好的抽象机制
1.支持值类型（包括类）
2.支持静态类型关系（static type relationship）和动态派发
4.支持可回溯的模型设计
5.不存数据
6.没有初始化负担
7.明确接收者要实现什么（与类方法重载的模糊性形成对比）
五、Swift是一门面向协议（Protocol-Oriented）的编程语言
六、一切从协议开始
1.避免了书写不必要的方法实现代码
2.不再需要重载
3.在协议方法定义中中使用self来解决类型关系丢失（Lost Type Relationship）
protocolOrdered
precedes(other:
Self) -&Bool
4.将异质声明转化为同质
当Ordered为Class时:
funcbinarySearch(sortedKeys:
[Ordered], forKey k:Ordered)
hi = sortedKeys.count
mid = lo + (hi - lo) /
sortedKeys[mid].precedes(k) {
&&&&&&&&&&& lo = mid +
&&&&&&&&&&& hi = mid
当Ordered为Protocol时:
funcbinarySearch&T:
Ordered&(sortedKeys: [T], forKey k:T)
hi = sortedKeys.count
mid = lo + (hi - lo) /
sortedKeys[mid].precedes(k) {
&&&&&&&&&&& lo = mid +
&&&&&&&&&&& hi = mid
七、若你在Protocol 中使用Self ，Protocol 与Class 的差异会变的更大
1.采用泛型而不是类型
2.同质化而不是异质化的思考方式
3.类型实例之间的交流不再意味着两个类型之间的交流
4.采用效率更高的静态派发方式
八、协议拓展
语法见四天前的 Swift&2.0语法更新（二）&
Renderer 是Protocol，TestRenderer 是满足Renderer 的结构体。
第一张图对Renderer进行了拓展，添加了两个方法，一个是原protocol中要求的CircleAt 和新添加的RectangleAt。
第二张图对结构体TestRenderer进行了拓展，添加了两个相同的方法。
若以图二所示的方式定义r,&CircleAt会调用extension&TextRenderer中的CircleAt，而RectangleAt会调用 extension Render中的RectangleAt。
在该种定义方式中，优先级：在原协议中被未要求的协议拓展方法 & 类型拓展方法 & 在原协议中被要求的协议拓展方法。
九、More Protocol Extension Tricks 因水平有限暂不翻译
十、什么时候我们该用类
1.对实例的比较和复制没有意义的时候（例如：Window）
2.实例的生命周期取决于外部影响的时候（例如：暂时性的文件）
3.实例只能够被写入来影响外部状态（例如：CGContext）
4.而且不要对抗面向对象的系统API
十一、总结
Protocol & Superclasses
Extension protocol 很神奇
英文原版视频请见WWDC Session 408
我的热门文章Swift面向协议编程初探 - CSDN博客
Swift面向协议编程初探
最近有时间，挑了几个今年WWDC中比较感兴趣的Session视频来学习，今天就抽时间整理一下关于Swift 2.0中一个比较新的概念面向协议编程。
相关的Session视频链接如下：
面向协议编程是什么？
你可能听过类似的概念：面向对象编程、函数式编程、泛型编程，再加上苹果今年新提出的面向协议编程，这些统统可以理解为是一种编程范式。所谓编程范式，是隐藏在编程语言背后的思想，代表着语言的作者想要用怎样的方式去解决怎样的问题。不同的编程范式反应在现实世界中，就是不同的编程语言适用于不同的领域和环境，比如在面向对象编程思想中，开发者用对象来描述万事万物并试图用对象来解决所有可能的问题。编程范式都有其各自的偏好和使用限制，所以越来越多的现代编程语言开始支持多范式，使语言自身更强壮也更具适用性。
更多编程范式和相关概念请参看：
对Swift语言所采用的编程范式感兴趣的朋友可以参看这篇文章：
面向协议编程长什么样子？
在详细解释面向协议编程之前，我们先简单地概括一下面向协议编程长什么样子？它与我们熟悉的面向对象编程有什么不一样？
简单来说，面向协议编程是在面向对象编程基础上演变而来，将程序设计过程中遇到的数据类型的抽取（抽象）由使用基类进行抽取改为使用协议（Java语言中的接口）进行抽取。更简单点举个栗子来说，一个猫类、一个狗类，我们很容易想到抽取一个描述动物的基类，也会有人想到抽取一个动物通用的协议，那后者就可以被叫做面向协议编程了。什么？就是这样而已？苹果官方那么正式的称Swift是一门支持面向协议编程的语言，难道就是这么简单的内容？当然不会，有过面向对象编程经验的人都会清楚，协议的使用限制很多，并不能适用于大多数情况下数据类型的抽象。而在Swift语言中，协议被赋予了更多的功能和更广阔的使用空间，在Swift
2.0中，更为协议增加了扩展功能，使其能够胜任绝大多数情况下数据类型的抽象，所以苹果开始声称Swift是一门支持面向协议编程的语言。
面向协议编程对比面向对象编程的好处在哪里？它会对我们程序的设计造成哪些影响？我们会在下文中继续分析。
离开面向对象我们失去了什么？
首先，让我们来看看面向对象编程为我们带来的好处。绝大多数熟悉一种或几种面向对象编程语言的开发者都能随口说出几条面向对象编程的优点，比如数据的封装、数据访问的控制、数据类型的抽象、代码的可读性和可扩展性等。这意味着离开了面向对象编程我们也就失去了如此多的好处。
哦，天呐！不要这样好嘛？
回头仔细想想，这些好处只有面向对象编程才有嘛？苹果给了我们另一种答案：It’s Type, not Classes，是抽象的类型带给我们如此多的好处，并不是面向对象中的类，类只是抽象类型的一种方式。比如在Swift语言中，使用结构体和枚举也同样能够实现对类型的抽象、数据的封装和访问控制等，这些好处又都回来了。
那么有没有什么是类能带给我们，而结构体和枚举办不到的呢？当然有，不然我们真的可以离开面向对象了。面向对象编程还有两个非常重要的特性我们还没有提到：继承和多态。继承和多态为我们带来了丰富多彩的世界，想想我们Cocoa Touch中的框架，这才是我们所熟悉的面向对象编程，它使我们能够轻易地解决所面对的问题，并使我们的代码具有高度的可定制和可重用性。
我们的世界终于好像正常了。
拥有面向对象我们又得到了什么？
那么，面向对象编程在带给我们这么多好处的同时，是否还附带了其他一些特性呢？比如说：要花费的代价。
我们先来看出现的第一个问题，多数面向对象语言中的对象都是使用引用类型，在对象传递过程中只是将引用复制一份并指向原有的对象，这样就会出现问题。比如下面代码所示的例子：
class&Book&{
&&&&var&name:&String
&&&&var&pages:&Int
&&&&init(name:&String,&pages:&Int)&{
&&&&&&&&self.name&=&name
&&&&&&&&self.pages&=&pages
class&Person&{
&&&&var&name:&String
&&&&var&book:&Book
&&&&init(name:&String,&book:&Book)&{
&&&&&&&&self.name&=&name
&&&&&&&&self.book&=&book
let&围城&=&Book(name:&&围城&,&pages:&888)
let&小明&=&Person(name:&&小明&,&book:&围城)&
let&小刚&=&Person(name:&&小刚&,&book:&围城)&
小明.book.pages&=&88&
print(小刚.book.pages)&
故事的结尾是：小刚因为弄坏书被妈妈打了~ 不对啊，小明哪去了？我也不知道~
相信大多数面向对象编程语言的开发者都明白这是引用传递的原因，通常我们的解决办法也很简单，每次赋值的时候都先拷贝一份再进行赋值。当我们尝试在上述代码中加入copy方法时，却发现在Swift中对象默认并没有copy方法，这是因为Swift更推荐使用值类型变量而不是引用类型的变量。如果真的需要调用copy方法，你可以将Book类继承自NSObject，但这样的做法真的一点都不优雅，也不够Swiftpyer。实际上我们的问题也可以采用如下的解决办法：
class&Book&{
&&&&var&name:&String
&&&&var&pages:&Int
&&&&init(name:&String,&pages:&Int)&{
&&&&&&&&self.name&=&name
&&&&&&&&self.pages&=&pages
class&Person&{
&&&&var&name:&String
&&&&var&book:&Book
&&&&init(name:&String,&book:&Book)&{
&&&&&&&&self.name&=&name
&&&&&&&&self.book&=&Book(name:&book.name,&pages:&book.pages)
let&围城&=&Book(name:&&围城&,&pages:&888)
let&小明&=&Person(name:&&小明&,&book:&围城)&
let&小刚&=&Person(name:&&小刚&,&book:&围城)&
小明.book.pages&=&88&
print(小刚.book.pages)&
我们在Person的构造方法中，为book属性新创建了一本书，从而保证小明和小刚各自拥有自己的书。这个解决办法可能并不适用于所有引用类型传递的情况，那么在Swift中，最好的解决办法是什么呢？其实答案很简单，使用值类型而非引用类型。Swift中许多常见的数据类型、字符串、集合类型，以及结构体和枚举都是值类型而非引用类型，值类型的变量在赋值时会自动进行一次低消耗的值拷贝，对比对象的copy要更加高效而且不存在线程安全问题。所以我们上面这个故事的最好结局是：将Book修改为结构体类型。
struct&Book&{
&&&&var&name:&String
&&&&var&pages:&Int
&&&&init(name:&String,&pages:&Int)&{
&&&&&&&&self.name&=&name
&&&&&&&&self.pages&=&pages
struct&Person&{
&&&&var&name:&String
&&&&var&book:&Book
&&&&init(name:&String,&book:&Book)&{
&&&&&&&&self.name&=&name
&&&&&&&&self.book&=&book
let&围城&=&Book(name:&&围城&,&pages:&888)
var&小明&=&Person(name:&&小明&,&book:&围城)&
let&小刚&=&Person(name:&&小刚&,&book:&围城)&
小明.book.pages&=&88&
print(小刚.book.pages)&
小刚终于得救了~
想了解更多值类型的使用及其相关信息可以参看：
我们刚刚使用一个例子解释了面向对象编程中使用引用类型可能出现的问题，接下来我们谈论另一个非常重要的话题：继承的代价。这并不是一个新颖的话题，自面向对象编程诞生之日起就饱受争议，我们经常要忍受着愈加繁杂和庞大的继承体系来获得代码的可重用性，而且随着继承层次的增加，代码的复杂性会加速增长，随之而来的bug也会越来越难以发现。这时我们可能需要依靠设计模式来找回我们的思路，然而大多数设计模式只能帮助你理顺你的代码结构，却在同时更加加深了你的代码的复杂度。
继承带给我们的另一个好处就是多态，多态极大地增强了我们代码的可扩展性。然而就像“能量守恒定律”一样，多态也带来了一定的负面影响，那就是类型信息的缺失。形象一点讲，就是我们常常会写出这样的代码：subClassObject as! SubClass，向下类型转换。
那么问题来了：什么是更好的抽象类型？
苹果官方对这个问题的回答如下：
更多地支持值类型，同时也支持引用类型
更多地支持静态类型关联（编译期），同时也支持动态派发（运行时）
结构不庞大不复杂
模型可扩展
不给模型强制添加数据
不给模型增加初始化任务的负担
清楚哪些方法该实现哪些方法不需实现
其实答案就是Swift中的面向协议编程，苹果只是在自卖自夸而已。
面向协议编程
接下来我们就正式进入Swift的面向协议编程的世界。首先我们来对比如下两段示例代码，代码的功能是定义一个更具扩展性的二分查找法。
class&Ordered&{
&&&&func&precedes(other:&Ordered)&-&&Bool&{&fatalError(&implement&me!&)&}
class&Number:&Ordered&{
&&&&var&value:&Double&=&0
&&&&override&func&precedes(other:&Ordered)&-&&Bool&{
&&&&&&&&return&self.value&&&(other&as!&Number).value
func&binarySearch(sortedKeys:&[Ordered],&forKey&k:&Ordered)&-&&Int&{
&&&&var&lo&=&0
&&&&var&hi&=&sortedKeys.count
&&&&while&hi&&&lo&{
&&&&&&&&let&mid&=&lo&+&(hi&-&lo)&/&2
&&&&&&&&if&sortedKeys[mid].precedes(k)&{&lo&=&mid&+&1&}
&&&&&&&&else&{&hi&=&mid&}
&&&&return&lo
protocol&Ordered&{
&&&&func&precedes(other:&Self)&-&&Bool
struct&Number:&Ordered&{
&&&&var&value:&Double&=&0
&&&&func&precedes(other:&Number)&-&&Bool&{
&&&&&&&&return&self.value&&&other.value
func&binarySearch(sortedKeys:&[T],&forKey&k:&T)&-&&Int&{
&&&&var&lo&=&0
&&&&var&hi&=&sortedKeys.count
&&&&while&hi&&&lo&{
&&&&&&&&let&mid&=&lo&+&(hi&-&lo)&/&2
&&&&&&&&if&sortedKeys[mid].precedes(k)&{&lo&=&mid&+&1&}
&&&&&&&&else&{&hi&=&mid&}
&&&&return&lo
应该不难看出两者之间的区别以及孰优孰劣，简单解释一下前者的缺点，反过来也就是后者的优点了。
OC语言中没有抽象类这个概念，所有抽象类都是靠文档注释标明，这很蛋疼~
其他类型若想使用该二分查找法，必须继承自Ordered抽象类，在单继承体系中，该类型将无法再继承其他类型
方法参数接收的数组中，类型要求不严格，可以放入多种不同类型的Ordered子类对象
基于前一点原因，为保证严谨性，必须在方法实现内部增加类型判断，这更加蛋疼~~
基于上面的例子，我们可以稍微感受到面向协议编程在扩展性上的优势了，这里再提几个注意点。
Swift 2.0新特性之一，将Self用于约束泛型，功能类似于OC中的instancetype，示例：extension Ordered where Self: Comparable
Swift&2.0另一个重要的新特性，协议可扩展，意味着你不仅可以扩展一个类型使其遵守Ordered协议，还可以直接扩展某个协议，详见如下两段代码示例。
extension&Int:&Ordered&{
&&&&func&precedes(other:&Int)&-&&Bool&{
&&&&&&&&return&self&&&other
extension&String:&Ordered&{
&&&&func&precedes(other:&String)&-&&Bool&{
&&&&&&&&return&self&&&other
let&intIndex&=&binarySearch([2,&3,&5,&7],&forKey:&5)&
let&stringIndex&=&binarySearch([&2&,&&3&,&&5&,&&7&],&forKey:&&5&)&
extension&Comparable&{
&&&&func&precedes(other:&Self)&-&&Bool&{
&&&&&&&&return&self&&&other
extension&Int:&Ordered&{}
extension&String:&Ordered&{}
let&intIndex&=&binarySearch([2,&3,&5,&7],&forKey:&5)&
let&stringIndex&=&binarySearch([&2&,&&3&,&&5&,&&7&],&forKey:&&5&)&
从上面的代码我们可以看出，协议可扩展所带来的功能之一就是能够为协议中的方法提供默认实现。
更多协议可扩展所带来的功能可以参看RayWenderlich上的这篇文章：
关于面向协议编程的完整示例程序可以参看苹果官方的示例代码：
完整示例程序：
面向对象编程和面向协议编程最明显的区别在于程序设计过程中对数据类型的抽取（抽象）上，面向对象编程使用类和继承的手段，数据类型是引用类型；而面向协议编程使用的是遵守协议的手段，数据类型是值类型（Swift中的结构体或枚举）。
面向协议编程是在面向对象编程基础上发展而来的，而并不是完全背离面向对象编程的思想。
面向对象编程是伟大的编程思想，也是当今主流的编程思想，它的问题在于被过多的使用在其实并不需要使用它的情况下。
Swift是一门支持多编程范式的语言，既支持面向对象编程，也支持面向协议编程，同时还支持函数式编程。在项目开发过程中，控制器和视图部分由于使用系统框架，应更多采用面向对象编程的方式；而模型或业务逻辑等自定义类型部分，则应优先考虑面向协议编程。
PS. 这篇文章的写作过程持续了很长时间，中间几乎夭折，最后还是尽量将它写完整（其实后半部分写的很水）。面向协议编程是一个比较新的概念，目前只是隐约可以看出它的一些长处（在一些使用面向对象编程并不太适合的地方），不过苹果已经在自身框架中开始使用了，并确实改善了系统一些类型和方法的使用。
最后，让我们记住这张图：（Quiz: Who is Crusty at Apple?）
本文已收录于以下专栏：
相关文章推荐
实际上这篇文章改编自我对数据结构链表的笔记，只是我没有想到，当我想要用 Swift 来实现链表的时候，会发生这些有趣的事情。同时还让我对面向协议编程做了一次实践。
于是就有了这么一个唬人的标题，因为...
iOS — 面向协议的编程（swift）
下面简单的介绍面向协议的编程的应用扩展协议和默认实现
面向协议编程
swift是面向协议的编程语言
UIKit中的委托模式
创建自己的...
什么是swift协议？Protocol
Swift标准库中有50多个复杂不一的协议，几乎所有的实际类型都是妈祖若干协议的。protocol是Swift语言的底座，语言的其他部分正是在这个底座上组织和...
协议定义了某一批所要遵循的规范，但不关心类的内部状态数据，也不关心类方法的实现细节。它只规定类中必须提供的方法。类、结构体、枚举通过提供协议所要求的方法，属性的具体实现来采用协议。
    任意能够...
一、使用类的好处
3.采用命名空间来避免冲突
4.表意性极强的语句
5.可拓展性
在Swift中，前三点使用结构体和枚举就也完全可以实现。
二、在以往...
在 WWDC 2015上，苹果发布了 Swift 2.0 版本，这是自 Swift 发布以来进行的第二次重大改版，这次改进推出了很多新特性来帮助我等程序员写出更优雅的代码。
在这些新特性里面，最...
1、原先的实现过程我们一般使用的是Alamofire，对其单例封装
NetworkTools.swift
Created by targetcloud on 2017...
本文从我们经常遇到的简单实例入手，为您展示最简单的面向协议编程入门：首先我们是不是经常遇到下面的代码：注册cell
tableview.register(UINib(nibName: &XXC...
转载注明出处:http://blog.csdn.net/qxuewei/article/details/
因为OC 的局限性, 使得iOS 开发组件化编程变得不可能,得益于面向对象...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)