Android项目重构之路:架构篇 读后思考

由于本人写代码逻辑比较多，所以现在针对这方面也在进行不断增强，最近偶尔看到一个项目经理在进入新公司时针对代码的结构设计，我在解读之后，针对其思维进行一些思考，每当想到更多会再编辑一次

我所针对的文章地址是：Android项目重构之路:架构篇

这张图中的结构与我一般脑中的MVC结构略有不同，所以导致我一开始无法很理解，但是后来我理解了，这里的模型层就是我们定义的bean，可以说这里面都是围绕着模型层来进行

,这种结构与我之前写的代码都有所不同，可以说这种接口思维正是我有所欠缺的，在这中，模型层作为贯穿三层的bean，它本身是否应该包含逻辑，比如当这个bean是一只狗，那么这只狗他会叫，那么这时候，“叫”这个功能它应该放在哪里，他应该放在模型层，还是放在核心层？如果是以MVC的思维来说，功能的实现放在控制层，但是这里呢？

博主给出的代码中，核心层的代码是登陆+获取用户bean（整体功能是登陆显示），接口层是访问网络并解析Bean，界面层就是显示。如此看来的话应该是看这款软件的主要功能是什么，软件的整体不是一只狗，一般来说是一个动物，或者说可以加载很多只狗，每只狗不一样，或者略微不同，那么，这个时候，叫这个功能应该就是狗自带的，如果狗的叫声要进行扩展，例如可以替换不同的叫声，那么这时候就需要将叫声封装为对象，叫声自己有播放功能。这个时候，一些表现的功能就完全是由模型层来完成，在这里，获取狗的声音的时候是从狗来获取，但是当要替换狗的声音时，应该是由核心层来完成（之前纠结于换狗的声音时，这里的逻辑由谁来负责）。替换狗的声音狗自己是做不到的

这样就是，属于模型层的职能的由模型层来实现，比如：狗“叫”，但是超出其职能的由核心层来完成

到这里，整理一下目前的结构：

界面层：所需界面的显示，包含界面自己的操作逻辑

核心层：包含逻辑的主要方法调用，超出模型层能力的部分，比如我需要获得用户对象，那么我需要先登录然后才能获得用户对象，用户没有办法初始化自己，需要模型层，狗没有办法替换自己的声音，他只会使用（叫），需要核心层来完成

那么核心层的这个方法就包括了登录+获取对象并返回

接口层：每个单独功能的接口定义与实现，比如登录一个接口，获取对象一个接口

（这里有一点需要思考，就是以后在模块之间交互的接口，与这里的接口的区别）

模型层：功能需要的主要对象，例如用户对象、狗，用户显示用户信息，狗可以叫等

到这里，一个基本的结构+功能（只能）分配就完成了，时间也比较晚了，找时间还可以对这套结构进行扩展，不断针对实际的项目进行思考与优化