面向协议的编程：
https://realm.io/cn/news/appbuilders-natasha-muraschev-practical-protocol-oriented-programming/
思考：大型工程，大型公司的结构和框架是咋样的，现实生活中的例子有没有？中共是如何组织协调事务的。各个部门的职责是什么，应该做什么，不应该做什么。部门之间时怎样协调工作的？ 我们平常签署的协议有什么好处和坏处。
原则：用清晰的框架架构，和明了的表达使得程序APP具有可读性，可维护性，以及可扩展性。
问题：结构清晰吗
（1）多人可以协同工作嘛。
（2）可插拔，可替换吗？易于修改，维护吗？
（3）可读性强吗
（4）易于写测试代码吗
方法：
（1）少用继承，多用协议（面向接口编程）和category。想想我们日常生活中与人打交道，特别是陌生人，如果有一份协议，就可以免除许多的误会。eg，租房卖房协议，这样彼此就清楚了自己和对方的责任和义务。如果有个麻烦，找协议就可以了。因为这是双方协定好的。
（2）流水线作业，每个类，方法只做一件小小的，独立的事情。专业的人做专业的事情，不要越权，管闲事。如果需要调度，找更高级的领导。 就像富士康的工人。
（3）分层次，就像http协议一样。
（4）各个模块不能直接交流通信，如果需要通信，必须找指挥官。
（5）设计模式在这里可以发挥作用吗。a，业务模块和与之关联的非业务模块，建议使用适配器模型。
需要考虑的事情：业务，模块之间使用协议，接口通信。
业务逻辑，非业务的事项。各个模块提供给其它模块的，必须是以接口的形式。
问题：模块可复用吗？
模块方便测试吗？
各个模块的职责是什么？模块之间是怎样传递消息的？
（1）各个模块：各个模块的角色，模块之间交流的方式。
模块定义了两个协议。一个是模块接口，它定义了模块可以做什么；另一个则是模块的代理，用来描述该模块做了什么
特点：View模块和Model模块无法直接沟通，需要通过ViewController间接的沟通交流。
a，Model Layer：代表了专业知识。
Model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data
User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.
b，View Layer：代表了视图。
A view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions.
Communication: View objects learn about changes in model data through the application’s controller objects and communicate user-initiated changes—for example, text entered in a text field—through controller objects to an application’s model objects.
c，ViewController Layer：协调器
A controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects.
MVC模式的缺点：好多事情都在ViewController中做了，当项目越来越大时候，VC里面太混乱了。
而对于View Layer，它显示需要的数据似乎也和专业知识不太相关。
MVVM模式：https://www.raywenderlich.com/74106/mvvm-tutorial-with-reactivecocoa-part-1
相对于MVC而言，当代码越来越庞杂情况下，ViewController可能太臃肿了。把影响VIew Layer的表示逻辑从 Controller 移出放到一个新的对象里，即 View Model。View Model Layer仅仅存放了影响View Layer的视图逻辑，例如把一个NSdate转换为@“YY MM RR ：SS”格式的数据。
MVVM模式缺点：数据绑定的使用使得Bug很难调试。因为数据绑定会使得一个位置的bug很快的传递到别的地方，要准确的找到错误源就不是那么容易的事情。
VIPER模式：我理解的是MVVM模式的加强版，更加细化责任。让不同的，专业的类负责处理具体的事物。https://blog.coding.net/blog/ios-architecture-patterns
View Layer：视图，负责展示view，和接受外部输入，eg：点击，触摸等。
（ViewController指挥官，负责调度）
Interactor：接受View中的事件，在其中处理好所有与业务相关的事务，抽象好数据，并将向Entity发出事务处理请求（注意，这时已经脱离了具体的业务相关事务）。
Entity：在此层处理脱离了业务相关的事务，eg，数据库的操作，网络的请求。
Presenter：包括ViewModel，负责提供给View的数据，这些数据必须View可直接使用。
Routes：负责跳转，JLRoutes。
单例模式：https://duckrowing.com/2010/05/21/using-the-singleton-pattern-in-objective-c/
当有人copy单例时候，如何保障单例是唯一的？调用-(id)alloc方法底层会调用+(id)allocWithZone:(NSZone*)zone，在里面保证唯一的。
在-(id)copyWithZone:(NSZone*)zone{ return self;}
RunTime：刨根问底runtime
这个类对象必须是一个 Meta Class 的实例，而这个 Meta Class 同时也是一个根 MetaClass 的实例。
BeeHive框架：模仿spring框架
REACTIVECOCOA研究
（1）子模块的structure，BeeHive
（2）列表模块的数据获取，数据处理，显示等。
a，网络请求
b，缓存
（3）不同VC之间的跳转
（4）与网页的交互的structure。
业务逻辑
视图逻辑
OBJECTIVE消息转发机制在框架设计中的应用：
+ (BOOL)resolveClassMethod:(SEL)sel
- (id)forwardingTargetForSelector:(SEL)aSelector
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector;
- (void)forwardInvocation:(NSInvocation *)anInvocation
可以利用IOS的消息转发机制，发出虚假的消息（例如，调用不存在的方法），使用转发机制，拦截自定义的消息，发送给代理proxy，集中处理。
http://studentdeng.github.io/blog/2014/08/29/ios-architecture/
MVVM模式学习
https://github.com/lovemo/MVVMFramework
http://www.cocoachina.com/ios/20160301/15425.html
