clean architecture的核心思想

------前言

安卓开发半年有余了，感觉遇到一些比较具体的问题，比如要搞个特殊的view啊，加个缓存啊什么的都不是太困难的事，基本上stackoverflow上，博客上找一找都有，还有多开源包可以用。倒是对app整体的架构设计上感觉不是那么有底：谁都知道要“解耦”，具体怎么解，解到什么程度，反正我是不太明白。网上看了一下，国外比较多的就是所谓的clean architecture的架构设计，除了一些直接翻译国外文章的，中文的资源几乎没有。于是研究了一下这个架构，感觉还是颇有收获的，打算在这里整理一下。内容很多，感觉要一下写完实在太累。 初步打算按照以下的顺序来写：

0-clean architecture的核心思想
1-安卓实现clean architecture的大体思路   点击打开链接
2-Repository pattern+MVP+RxAndroid   点击打开链接
3-Dagger/ButterKnife
4-unit test/functional test

----clean architecture的核心思想

clean architecture应该是uncle bob（R.C.Martin，不是RR Martin，那个是写冰与火之歌的 ）提出的。通过学习R.C.Martin关于clean architecture的报告
（ 点击打开链接 打开的时候可能需要科学上网，油管上也有不少他的其他报告，感觉核心内容差不多）我认为clean architecture最最核心的东西就是OOD的SOLID设计原则。当然SOLID稍微是抽象了一点，clean architecture更加具体一点。


在uncle bob的报告中讲了以下几个问题

1 什么是（不是）架构？
--> JAVA/ECLIPSE/SPRING/HIBERNATE/TOMCAT/MYSQL/MVC 这些不是架构，是工具(原话 list of tools)
--> 一个系统的架构应该能指示这个系统的用途，以及系统中各个较高层次模块的用途。
--> 比方说如果问你房屋的架构是什么，显然你不应该说是榔头，钉子什么的，这些是工具。你应该拿出房屋的平面图。如果图纸上画着一排一排书架，还有一些桌子，别人会猜这是个图书馆；如果图纸中间画着圣坛，一排排椅子，别人会猜这是个教堂。

2 何为好的架构？  
-->好的架构延迟系统需要做出的选择。
-->比如说系统需要决定用什么数据库，用什么网络通信框架，ui用什么风格。对于一个设计良好的架构来说，这些选择不必在一开始做出，或者说好的架构应该可以兼容任意的选择。数据库/通信/UI框架都是工具，好的架构让系统来自由选择工具，而不是让工具来决定系统。
-->相同的意思，另外一个说法：架构应该在较高层次一目了然指出模块的作用，而模块具体的实现是细枝末节。
-->UseCase 与UI分离，UseCase是什么：系统能处理的逻辑或者说能处理的任务。
-->自由选择数据库、网络意味着单元测试可以很快（用mock DB， mock server）

3 clean architecture是怎么样的?

  （下面图片均截取自 Uncle bob 的报告 点击打开链接 ，大牛就是大牛PPT都是手写一下然后扫描一下。。）

3.1 ： 每一个UseCase用一个Interactor类和业务逻辑交流，  Interactor 是与程序相关的， Entity 处理业务逻辑是与具体程序不相关的。

   （图3.1）

3.2 : Interactor通过boundary接口拿到UI给的request,找到需要的entity,给出输出的response(同样通过boundary接口到UI)。  这样有啥好处？ UI通过接口与Interactor关联，这样的Interactor易于测试，不依赖于ui具体实现。

（图3.2）

3.2  如何处理UI？ Presenter实现了boundary接口。同样Presenter/ViewModel也都是易于测试的。而且这样的UI易于替换。如果处理DB也是类似的思路，Interactor通过接口与DB传递信息。

（图3.3）