- 博客(6)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 关于“幽灵架构”的总结：适用场景与方法重载
前几篇博文对“幽灵架构”做了用法的介绍和相关技术点的补充，本文是一篇总结性质的文章，分析该架构的适用场景和限制，首先让我们回顾一下iOS开发的MVC模式，参考斯坦福公开课里Paul老爷子的讲解，如下图所示： 在MVC模式下Model和View是不能直接通信的，在“幽灵架构”体系中Model和View依旧不能直接通信，在传统的MVC中，这种通信的阻隔很多时候是因为在没有得到Model和View实
2016-05-13 12:02:40
6587
5
原创 关于“幽灵架构”的补充说明5：改造控制器
Swift中的泛型有非常多的用处，除了我在之前介绍的方法中作为占位符之外，还可以被用在协议中，构成一个泛型协议，那么遵守这个泛型协议的成员就会变成泛型成员。还用我们之前的事件节日提醒Demo来展示，在之前的版本中我们使用了一个TableView来展示数据，现在如果有新的需求，需要在CollectonView中做类似的排列，并且针对数据源提供日期的筛选功能，面对相似的功能需求显然你不想写两份代码，那么
2016-05-12 23:24:49
5615
1
原创 关于“幽灵架构”的补充说明4：协议的应用场景与局限性
再次解释一下协议的意义：定义某个功能模块的最小粒度，因为Swift是单继承，而无论是值类型还是引用类型都可以遵守多个协议，因此协议是比父类的粒度还要小的功能模块。协议的功能定义一定要具体并且严格，someObject:Protocol where …中where子句的匹配条件只能针对someObject的类型或者遵守的其他协议，以及Protocol中的associatedType的约束，也就是说不能
2016-05-12 10:45:45
5026
原创 关于“幽灵架构”的补充说明3：为什么不会产生“循环引用”
承接上文，已经简明阐述了使用Struct代替Class的好处，使用Class会使我们的程序出现“意外的共享”以及“循环引用”之类的危险，传统面向对象开发中对Class的依赖主要来自于我们对“继承”的依赖。Swift2.0引入协议扩展后，之前的“类-继承”所能实现的功能使用“结构体（枚举）-协议-协议扩展”都可以实现，并且更加高效和灵活。回到主题上来，首先回顾下“幽灵架构”中的两个主体：View和Mo
2016-05-11 23:57:20
4336
原创 关于“幽灵架构”的补充说明2：Struct以及Copy - on -Write
在“幽灵架构”Demo中我把两个数据模型声明成了Struct，苹果WWDC2015的414号视频讲解了非常多关于Struct的优势，其实也是所有值类型的优势。首先Swift标准库中绝大部分是值类型的，值类型的值传递是通过copy的，而作为一门静态语言，Swift要求所有的对象都有明确的类型，明确的类型代表了固定的内存分配，而414号视频也指出在内存中进行定长对象的copy是时间常数的，也就所谓的“c
2016-05-11 14:38:13
2332
原创 关于“幽灵架构”的补充说明1：协议中的方法定义
承接上一篇博文，上一篇的篇幅有点太长了，我觉得有一些相关的技术点需要说明，所以重新写几篇博文。这个系列的文章将要说明以下几个问题： 1.giveData和getData在各自协议中的位置 2.使用struct代替class的好处 3.“幽灵架构”为什么不会产生循环引用 4.协议的应用场景与局限性 5.运用面向协议编程思想改造控制器 让我们来简单回顾下这个架构，如果不明白的可以参考上一篇博
2016-05-10 23:37:45
7176
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人