汤坤

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。而单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则和迪米特法则作为设计模式的六大原则，是我们在编码过程中所要遵守的。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的实现操作，把展现细节的任务交给它们的实现类去完成。

去年10月底换到了新公司，做移动研发组的负责人，刚开始接手android项目时，发现该项目真的是一团糟。首先是其架构，是按功能模块进行划分的，本来按模块划分也挺好的，可是，他却分得太细，总共分为了17个模块，而好几个模块也就只有两三个类而已。但应用本身其实比较简单，要按功能模块来分的话，最多五个模块就够了。另外，有好多模块划分也很模糊，也有很多类按其功能其实可以属于多个模块的，也有些类定义不明确，

在前一篇文章《Android项目重构之路:架构篇》中已经简单说明了项目的架构，将项目分为了四个层级：模型层、接口层、核心层、界面层。其中，最上层的界面，是变化最频繁的一个层面，也是最复杂最容易出问题的一个层面，如果规划不好，很容易做着做着，又乱成一团了。要规划好界面层，至少应该遵循几条基本的原则：保持规范性：定义好开发规范，包括书写规范、命名规范、注释规范等，并按照规范严格执行；保持单

前两篇文章Android项目重构之路:架构篇和Android项目重构之路:界面篇已经讲了我的项目开始搭建时的架构设计和界面设计，这篇就讲讲具体怎么实现的，以实现最小化可用产品(MVP)的目标，用最简单的方式来搭建架构和实现代码。IDE采用Android Studio，Demo实现的功能为用户注册、登录和展示一个券列表，数据采用我们现有项目的测试数据，接口也是我们项目中的测试接口。项