最近找了些理论，可以丰富自己的表达喔

1.用代码写界面有哪些好处？
1.1 Storyboard的XML结构很复杂，如果用storyboard，合并代码时容易冲突，比代码写界面要麻烦的多。
1.2 用代码写界面时，构建和重用view更加方便，能保持你的codebase遵循DRY原则（DRY：Don’t Repeat Yourself，指在写代码的时候尽量避免重复的实现）。
1.3 所有的信息都集中在一处。如果用Interface Builder，你还得到处点开各种检查器，才能找到你要设置的属性。

2.用StoryBoard画界面有哪些好处？
2.1 开发迭代更快，不需要build工程就能预览做出修改。
2.2 在Xcode6 中，在Storyboard里可以自定义字体和UI控件样式。
2.3 iOS8开始，可以用Size Classes设计同事支持屏幕尺寸的界面，省去很多重复工作。

3.用架构有哪些好处？
3.1 任务均衡分摊给具有清晰角色的实体
3.2 可测试性通常都来自与上一条（对于一个合适的架构是非常容易）
3.3 易用性和低成本维护

4.用MVC，MVP，MVVM设计模式的分类？
4.1 Models – 负责主要的数据或者操作数据的数据访问层，例如DBHelper
4.2 Views – 负责表示层（GUI），对于iOS环境可以联想一下以UI开头的所有类
4.3 Controller/Presenter/ViewModel – 负责协调Model和View，通常根据用户在View上的动作在Model上作出对应的更改，同时将更改信息返回在View上

5.将实体进行划分有哪些好处？
5.1 更好的理解它们之间的关系
5.2 复用（尤其是对View和Model）
5.3 独立的测试

7.MVC、MVP、MVVM三个特性的评估？
7.1 任务均摊：
7.1.1 MVC：View和Model确实是分开的，但是View和Controller却是紧密耦合的。
7.1.2 MVP：最主要的任务划分到Presenter和Model，而View的功能较少。
7.1.3 MVVM：View要比MVP中的View承担的责任多。MVVM通过ViewModel的设置绑定来更新状态，而MVP只监听Presenter的事件但并不会对自己有什么更新。
7.2 可测试性：
7.2.1 MVC：由于糟糕的分散性，只能对Model进行测试。
7.2.2 MVP：非常好，由于一个功能简单的View层，所以测试大多数业务逻辑也变得简单。
7.2.3 MVVM：ViewModel不知道关于View的任何事情，允许测试ViewModel。同时View也可以被测试，但是属于UIKit的范畴，通常被忽略。
7.3 易用性：
7.3.1 MVC：与其他几种模式相比最小的代码量，维护较为容易。
7.3.2 MVP：代码量是MVC模式的两倍，同时MVP的概念非常清晰。
7.3.3 MVVM：代码量与MVP差不多，在实际开发中，我们必须把View中的事件指向Presenter并且手动的来更新View，使用绑定的话，MVVM代码量将会小很多。

**就开发速度而言，Cocoa MVC是最好的架构选择方案。
iOS 中的MVP意味着可测试性强、代码量大**

8.VIPER–把LEGO建筑经验迁移到iOS app的设计：
VIPER是迄今为止划分责任的粒度是很好的选择。VIPER在责任划分层面进行了迭代。
8.1 交互器：包括关于数据和网络请求的业务逻辑，例如创建一个实体（数据），或从服务器中获取一些数据，为了实现这些功能，需要使用服务、管理器，但是不被认为是VIPER架构内的模块，而是外部依赖。
8.2 展示器：包含UI层面的业务逻辑以及在交互器层面的方法调用。
8.3 实体：普通的数据对象，不属于数据访问层次，因为数据访问属于交互器的职责。
8.4 路由器：用来连接VIPER的各个模块。
VIPER与MV（X）系列任务均摊是的区别：
Model逻辑通过把实体作为最小的数据结构转换到交互器中。
Controller/Presenter/ViewModel的UI展示方面的职责移到了Presenter中，但是并没有数据转换的相关操作。
VIPER是第一个通过路由器实现明确的地址导航模式。
任务均摊：VIPER是任务划分中的佼佼者。
可测试性：更好的分布式有更好的可测试性。
易用性：维护成本高，为很小的功能的类写出大量的接口。

找到一个适合的方法来实现路由对于iOS应用是一个挑战，MV(X)系列避开了这个问题

6.通知模型：
6.1 Delegation：（一对一）苹果官方经常用这个模式，主要用于回传，比如模态回传数据。
6.2 Callback blocks：（一对一）耦合更松，同时让相关联的代码在一起，消息发出者数量很多时比delegation更方便。
6.3 Notification Center：（一对多）可能是一个对象给多个观察者发出“通知”时最常用的方法。耦合非常松，甚至可以把通知发到全局们不需要对调度者的引用。
6.4 Key-Value-Observing（KVO）：（一对多）不需要被观测的对象主动“发出通知”，只需要被观测的键（属性）支持Key-Value-Coding（KVC）。这种模式比较含混，而且标准API比较繁复，所以一般不推荐使用。
6.5 Signals：（一对多）这是ReactionCocoa的核心。它允许结合关键内容的链式调用，用这种方法逃离回调深渊（嵌套过多的回调）。