标签：
上篇随笔随（Android 设计随便说说）便说了一下什么是设计以及设计的原则，这里举一个简单的例子来进一步的说Android设计。我们以应用商店的设计来举例。
在设计之前，需要把握两部分内容，才能使得设计更加的合理，恰当。
第一部分是应用本身包含的业务都有哪些。应用商店的业务大体上有一下几个：
1 给用户展示apk信息
2 提供用户下载apk
当然了已上还可以继续细分。但是对于我们的例子来说已经足够了。
第二部分本地sdk，也就是手机能够提供哪些接口。对于上面的分析我们需要了解一下API。
第一，界面展示的API能否支持。
第二，网络是否支持socket，
假设我们已经熟悉了应用商店的基本业务和需要的API，现在就开始我们的设计之旅。
在上一篇我提到了两个较为关键着手点。一是模块划分，二是合理组合。
说模块划分之前需要说明的是什么是依赖，什么是接口。
所谓的依赖，就是模块对外界类的调用的方法。所谓的依赖倒置是原来模块对外界的依赖是实现，现在模块对外界的依赖是虚接口。如果外界实体可以实现需实现虚接口，才可以和模块实现依赖。
所谓的接口，就是模块对外界提供的调用的方法。有两种，一种是直接的一个public方法。一种是以接口的形式，告诉外界。
我们先说应用商店的模块划分。
首先需要UI部分，UI的作用是什么？UI的作用有两个，一是给使用者展现信息，二是提供给使用者一个操作的平台。因此UI部分需要数据，而这些数据的来源需要其他模块的支撑，除非是一个helloworld程序。当然了在UI进程中不能做耗时操作，否则出现ANR。因此不允许在UI中网络请求。
例举一个页面RecommendActivity，apk推荐页面。
RecommendActivity（实体类，用户用户操作）对外的接口是
和接口类RecommendInterface（Interface，底层数据改变更新到界面）
..............
RecommendActivity依赖是RecommendBase（Interface或虚基类，用于实现类的继承）
..............
第二部分，网络请求模块。负责从服务端获取APK数据。
NetTaskManager（实体类）网络任务管理，这一模块的接口类。它依赖于HttpGet，HttpConnect等网络接口实现业务，已经是底层，依赖API即可。那么他提供的接口有哪些。
................
上面都是正向接口，但是它还需要将请求结果上报，由因为该模块的实现是异步完成的，因此还需要定义一个回调NetTaskResultListener（接口）提供以下接口
............
以上笼统的说了一下提供的接口。当然了还有一些细节这里不再计较。
第三部分，数据解析模块，从网络中来的数据流毕竟不能够直接使用，需要一个转换，这个模块就负责这个任务。
举例DataWorkManager（实体类） 负责数据的解析和组装。
它依赖的接口，实际上他需要对数据解析，是json或是xml都是依赖于API，因此它的依赖是API。
它提供的接口如下：
......
此外，这些数据的处理要看数据量是否大，耗时是否会长。如果，数据量不大，而且耗时不长，则同步即可，不需要提供回调。
.......
如果运算量较大，耗时长，则需要异步处理，需要提供一个回调接口。这里不再细说。
第四部分，下载模块，负责应用的下载。有人会问，下载也是从网络中请求数据，为什么不在网络请求模块中。原因是这两个模块功能完全不同，网络请求模块的职责是负责页面数据展示，随着页面的向下滑动，它需要同时不停的请求，如果页面跳转，则需要暂停原来的请求，进行新的请求。不确定性比较大。但是下载模块，职责是负责apk的下载。他需要区分网络是那种网络，而且下载是按照顺序的，除非人为改动。
例举DownLoadAppManager（实体接口类）对于外界的依赖，实际上还是网络接口的API。
对于外界的接口：
............
此外对外还有一个回调接口类DownLoadListener
.............
第五部分，调度模块，为了上面的四个模块有条不紊的实现业务，需要这个模块进行调度。这个模块是负责用户交互和业务实现的中间模块，对上层，负责接收用户的响应和提供UI界面数据。对下层，负责调度各个业务单元实现整体业务。
以Controller来命名该模块。
它需要提供的接口如下：
它还需要提供回调接口如下：
ControllerUIInterface
ControllerDownLoadInterface
ControllerDownLoadAppInfo
它需要依赖的接口ControllerDependInterface（虚类，或接口）。
1 针对网络请求
2 针对网络请求的数据处理
3 针对app下载
我们好好分析一下调度模块，它有二个功能，第一通过调度各个业务单元，从而实现整个业务。接受到界面指令之后，对指令进行拆分，综合结果并且上报。这样做的好处是业务统一处理。第二，它分割UI和各个业务单元紧密关联，通过添加一个层来隔离UI和各个业务，使得UI层和各个业务单元各自为政，互不干系。这样做的好处是业务单元不直接影响UI，结构扁平，增加稳定性。
但是这也有不好处，如果业务庞大的话，这样的调度模块就显得臃肿。当然了，另一个方法就是数据处理模块依赖网络模块，而调度模块不再依赖网络模块。这样由扁平成了垂直设计，无论怎么样，只要模块划分差不多，就容易在进行下去了。
模块划分就说明在这里。明天说合理组合部分。
标签：
原文地址：http://www.cnblogs.com/ouyanliu/p/5767061.html
