SOLID原则
1. 单一职责原则（SRP）
指每一个类都应该只有一种职责（功能）。
比如在设计视频模块时，视频播放和视频分享功能应该分成两个类来管理，而不是只用一个视频处理类。对于视频分享功能，完全可以将视频信息抽象为分享模块的一个数据体。
不符合单一职责原则的设计将使不关联的模块产生直接依赖性，耦合性更高。单一职责原则使得类或模块的设计更加专注。
2. 开放封闭原则（OCP）
开放指在设计时，对未来可能的扩展保持开放，对已经实现的代码或类保持封闭（尽量不会修改）。
比如一款健身App，目前支持跑步和瑜伽两种训练模式，提供开始训练，结束训练，训练打卡三个功能。
一种错误的设计是实现一个训练类，提供三个功能的接口，然后在三个功能内部通过枚举类型的训练模式，来区分处理。假如未来新版本需要增加一种拉伸身体训练模式，则训练类中三个接口都要改动。这违背了开放封闭原则。
那么按照开放封闭原则应该如何设计呢？可以将开始训练，结束训练，训练打卡三个功能作为训练的接口（Protocol），跑步，瑜伽，拉伸身体三个类分别实现该接口。
抽象类和接口如何选择？
一个类可以支持多个接口，但是只能有一个直接父类。抽象类中可以有非抽象方法，而接口只能有抽象方法。
因此，可以这样理解，继承是一个 "是不是"的关系，而接口实现则是 "有没有"（"是否支持"）的关系。在这里跑步，瑜伽和拉伸身体都支持开始训练，结束训练，训练打卡三个功能，因此用接口更合理些。
3. 里式替换原则（LSP）
指继承应当能确保父类的所有功能在子类中都生效。
比如正方形是一种特殊的长方形（宽高相等的长方形），很容易会将正方形设计为长方形的子类。但长方形类中有个同时设置宽高值的方法，正方形则不支持该方法，因此该设计不符合里式替换原则。
4. 依赖倒置原则（DIP）
指程序内部之间的依赖关系可以利用抽象接口来解耦，不要依赖于具体实现。可以等价的理解为面向接口编程。
即将业务逻辑线与其具体实现分离出来，业务逻辑线作为接口，具体实现通过该接口的实现类来完成。
在实际使用中，实现类可以抽象出公共的接口代替公共的方法，这样可将其它模块对公共方法的依赖转变为对接口的依赖。接口的耦合性更低。
5. 接口分离原则（ISP）
客户端不应该依赖于它不需要的接口，类与类之间的依赖应该建立在最小接口之上。
换句话说，接口的设计不应该责任太重，过重的接口容易造成臃肿，解耦困难，增加重构复杂度。
比如一个邮箱App，并设计了个邮箱接口，包含标星邮件，回复邮件，删除邮件和重新发送方法。两个类收件箱和发件箱都支持该接口，但对于收件箱而言，重新发送邮件是没有意义的，因此不符合接口分离原则。若将重新发送邮件放到一个新的错误接口中，发件箱支持它，则能很好的解决这个问题。
架构模式
MVC
下图代表iOS中的MVC架构：
在MVC模式下，容易造成Controll臃肿，代码可读性，可维护性差，因此中大型项目都不推荐采用。
MVP
面向协议（接口）编程MVP架构如下图：
实现代码如下：
一方面，Presenter为Controller解耦并减轻负担，另一方面面向协议编程将类与类之间的依赖转为类与协议（接口）的依赖，提升可维护性复用性。对于MVC下业务复杂的Controller，也可抽象出多个不同的Presenter。
MVVM
MVVM模式架构如下：
MVVM架构模式中建立了数据与视图的双向绑定，一般通过KVO或者响应式编程框架RAC或RXSwift来实现。
