Android外观模式的应用
这是一个`app`最初的项目结构
所有的页面都放在activities，自定义view放在widget，网络相关的封装在network，所有工具类放在utils，少数的xxxManager单例藏在某个包下面，因为少没必要过度提炼就这样吧…
没什么问题，项目上线！
随着项目迭代，越来越多的页面来了，数据库的表也多起来了，工具类更是爆炸性增长，还不排除有些工具类还在activity里面没来得及提炼出来，xxxManager散落一地，callback到处都是…各个包的类都在快速增长
如果用线来表示相互间的调用，那么整个项目就是一个毛线团，找代码都开始难找了
那么这时候就改理一理这个线团了
之前app没有一个明确的职责分层，横向依赖很严重，小改伤筋动骨
AppContext与外观模式的应用
随着业务的发展，app里面的组件，业务线也会逐渐的增多。
每个业务线一个module，那么新的问题就来了，module之间的通信问题，横向依赖问题。
每个module除了在自己的地盘处理业务，还有可能给其他module提供服务，或者这个module就是一个plugin风格的业务组件。
比较粗暴的做法，直接引用module，想调谁就引用谁，那么这和之前单module，类的横向引用又有什么本质上的区别呢？
这里我们可以借鉴下Android的Context类的设计，Context就是封装了一大堆Android的子系统（通过getSystemService获取），处理在Android环境下的通信问题。
那么我们可以依葫芦画瓢的设计一个我们自己的AppContext，我们的业务module或者组件都是在AppContext环境下，他们之间的通信就通过AppContext，具体业务就交给具体的module实现.
如果设计多个业务module的协作，那么也应该由AppContext屏蔽协作的细节，这是一个很典型的外观模式的应用。
在面向对象编程范式内，很多问题都可以通过引入额外的一层来解决
有些基础组件module或通用性非常高的module，可以下沉到AppContext下面
AppContext的核心职责就是封装好app所用到的子系统（审视下以前代码里面的单例manager，思考一下他是不是能作为app的一个子系统工作）来统一管理服务，无论该服务是基于Android，还是业务module，还是其他第三方组件。当然这里也应该module与app通信，一些app级别的配置也可以在这里处理
在实际操作中，一定要渐进式的处理，主要是因为：
- 互联网时代不能让飞机停下来，做到在天上就给飞机动了手术
- 可以逐渐验证自己的方案，不要一开始就置自己于险境
比如目前工程中moduleA直接依赖moduleB调用接口，重构过程中不必直接取消依赖（不要影响目前的业务），在AppContext中添加一个moduleB的service，这个service代理moduleB提供的接口服务，然后moduleA调用接口逐渐的转向AppContext提供的方式，当转得差不多的时候就断掉moduleA与moduleB之间的依赖。
对于有些业务线的module，完全可以把他当做一个app来对待
AppContext只是解决了module之间的通信或者是子系统的管理
由多收缩到一的问题（统一依赖AppContext），只限于单进程，还没有跨进程，跨app，关于跨进程local，remote的问题，另开一贴讲设计思路与实现
一个App除了通信，还有一些工具类，一些的style，theme，resource相关的定义。
很多app都会搞一个类似core，common的module，一股脑儿的扔里面，这玩意儿到后面绝对是一锅东北菜，乱炖的感觉。
对于module层级下面的util，只能是高度通用的util才放到下面，命名一定要体现其具体功能，千万不要直接utils，StringUtils等很模糊的命名，推荐Logger，DeviceUtil，UrlUtil等一眼就能看出其具体功能的util。
对于resource相关的定义，单独一个module
这些module都会逐渐沉淀下来，以后app按需依赖.
黑线一下的就是业务线开发的基础，是不是有点类似android.jar的感觉
UserCase
1 | 人之所以聪明，是因为人会创造工具并使用 |