Cwift的专栏

承接上一篇博文，上一篇的篇幅有点太长了，我觉得有一些相关的技术点需要说明，所以重新写几篇博文。这个系列的文章将要说明以下几个问题： 1.giveData和getData在各自协议中的位置 2.使用struct代替class的好处 3.“幽灵架构”为什么不会产生循环引用 4.协议的应用场景与局限性 5.运用面向协议编程思想改造控制器 让我们来简单回顾下这个架构，如果不明白的可以参考上一篇博

本人原创，长文慎入，但此文绝对不会让你失望。 WWDC2015已经过去一段时间了，我发现自从更新了Swift2.0到现在的Swift2.2，我只是跟着版本更新了所有需要更新的语法，依旧自以为是很熟练的Swift程序员。刚入职比较闲碰巧看到了1月份的中国首届Swift大会上大牛们的分享，突然陷入了思考，有了很多新想法又重温了几遍WWDC2015大会的视频，尤其是408和414号视频！！！我下定决心重

在“幽灵架构”Demo中我把两个数据模型声明成了Struct，苹果WWDC2015的414号视频讲解了非常多关于Struct的优势，其实也是所有值类型的优势。首先Swift标准库中绝大部分是值类型的，值类型的值传递是通过copy的，而作为一门静态语言，Swift要求所有的对象都有明确的类型，明确的类型代表了固定的内存分配，而414号视频也指出在内存中进行定长对象的copy是时间常数的，也就所谓的“c

再次解释一下协议的意义：定义某个功能模块的最小粒度，因为Swift是单继承，而无论是值类型还是引用类型都可以遵守多个协议，因此协议是比父类的粒度还要小的功能模块。协议的功能定义一定要具体并且严格，someObject:Protocol where …中where子句的匹配条件只能针对someObject的类型或者遵守的其他协议，以及Protocol中的associatedType的约束，也就是说不能

承接上文，已经简明阐述了使用Struct代替Class的好处，使用Class会使我们的程序出现“意外的共享”以及“循环引用”之类的危险，传统面向对象开发中对Class的依赖主要来自于我们对“继承”的依赖。Swift2.0引入协议扩展后，之前的“类-继承”所能实现的功能使用“结构体（枚举）-协议-协议扩展”都可以实现，并且更加高效和灵活。回到主题上来，首先回顾下“幽灵架构”中的两个主体：View和Mo

Swift中的泛型有非常多的用处，除了我在之前介绍的方法中作为占位符之外，还可以被用在协议中，构成一个泛型协议，那么遵守这个泛型协议的成员就会变成泛型成员。还用我们之前的事件节日提醒Demo来展示，在之前的版本中我们使用了一个TableView来展示数据，现在如果有新的需求，需要在CollectonView中做类似的排列，并且针对数据源提供日期的筛选功能，面对相似的功能需求显然你不想写两份代码，那么

前几篇博文对“幽灵架构”做了用法的介绍和相关技术点的补充，本文是一篇总结性质的文章，分析该架构的适用场景和限制，首先让我们回顾一下iOS开发的MVC模式，参考斯坦福公开课里Paul老爷子的讲解，如下图所示： 在MVC模式下Model和View是不能直接通信的，在“幽灵架构”体系中Model和View依旧不能直接通信，在传统的MVC中，这种通信的阻隔很多时候是因为在没有得到Model和View实