那些年我看到过的牛逼设计

• React：重分抽象了展示的过程，展示就是把数据放到View上的过程，View变化一定是某个数据变化。所以这种变化可以以状态机的形式存在，所有影响View显示的数据作为一个状态。通过对于状态的kvo，可以实现更为高层次的数据绑定，并不是一个View对应一个String这么简单。其实data-binding都是一样的，但是抽象成状态机会非常容易理解。
• Flux：又是Facebook做MVC抽象的一个设计。痛点在于原有的MVC模式上，C负责了V和M的更新，导致C的代码不好维护。
  抽象来说，App的主要目标都是展示操作数据，分以下功能模块（以登录为例）：
  
  • State（View Model）：唯一的对应着一个页面状态，React中的state，状态间是互斥的。如输入框状态（页面显示什么内容）、RPC状态（进度展示）
  • View Biz：显示相关的逻辑。如对于输入，是显示明文还是点点点
  • Biz：数据处理和业务逻辑。如处理RPC校验账密结果
  • View Event：UI的交互事件。如点击登录按钮
  • Event：业务逻辑事件。如RPC返回结果了
  • View：页面，纯视觉元素（React和Flux都没有特意把这个东西独立出来，都是揉在了View Biz里）
    整体来说，[View] Event会通过Biz改变State，State通过View Biz改变View。同时View又会发出View Event。
    Flux就是按上面的逻辑分层。Store对应着Biz，Action对应着两种Event，View对应View和针对本View的View Biz，Controller-View对应着整体的View Biz。
    为了解耦：
  • 所有层间事件传递都是以注册+回调的方式进行（这是解决痛点的地方）
  • 以消息队列的方式进行事件的传播（Dispatcher的作用），不会有过多的成串调用（callback中调callback）
• Redux 只有action、reducer和store。看起来就是flux的变种：
  
  • 没有消息队列
  • State不可变
  • reducer对应着flux的store，store对应着flux的dispatcher
  • 强调了一个页面一个state和reducer的回放作用，其实Reducer就是一个Command——一段逻辑的封装
• VueX同样是单中心Store、单线数据流、事件驱动。特点在于把业务逻辑也分了层：Actions和Mutations，Action是业务逻辑，Mutation是数据逻辑。没见过大项目，不知道这个分层好处在哪，但是代码似乎会更好维护。
• Clean Architecture：是一个架构的集大成者，做到最大化的隔离变化。看了一下Android10的例子，可能并没有get到核心点。按照UncleBob的说法，要有四层：
  
  • Entity：最核心不变式。个人看来可能不能反映到程序上，因为有些不变式是领域模型。或者可以强行说数据驱动的程序中的数据。这层由于没有多少逻辑在，所以什么都不依赖
  • UseCase：业务逻辑。必有的部分，是一些方法或模板方法，做成了最核心的原子业务功能，比如RPC之类的。这层会有模板方法的回调接口声明，只依赖Entity
  • Interface Adapters：交互逻辑，对应着Presenter（UncleBob说对应着整个MVP，这样来说，此处的M是ViewModel不是DomainModel，V是手写View的显示逻辑）。是整个程序功能的流程控制，相当于将核心业务逻辑（UseCase）粘到一起的粘合剂。这里面会有存储注册接口。
  • Frameworks&Drivers：外围系统，adapter模式的实现层，协调外部系统和上几层中的接口要求。