滥用全局
常量和全局方法
全局常量
在项目开发中，我们常常喜欢定义一个全局常量的类，把项目中用到的所有常量都定义到该类中。这让我们不用实例化对象，可以直接使用该常量。
public class GlobalConstant { public static final String IS_LOAD = "isLoad"; public static final String ACCESS_TOKEN = "accessToken"; public static final String REFRESH_TOKEN = "refresh_token"; public static final String IS_LOGIN = "isLogin"; public static final String CLIENT_TOKEN = "client_token"; public static final String IS_CLIENT = "is_client"; public static final String OPEN_ID = "open_id"; public static final String MMKV_KEY = "potato_key"; public static final String FANS_TOTAL = "fans_total"; public static final String FOLLOWINGS_TOTAL = "followings_total"; public static final String LIKE_TOTAL = "like_total"; } 复制代码
但实际上，定义所有全局常量到一个类中，并不是定义全局常量的最佳做法。
有以下几个缺点：
- 影响代码维护。当项目代码越来越多的时候，该常量类会变得十分臃肿。这会使得常量的查找以及修改变得费时，同时也会加大代码冲突的概率。事实上，import 的时候也会导入很多无用的常量。
- 增加编译时间。当依赖该常量类的代码越来越多，会使得修改了某一个常量后，造成所有依赖该常量类的代码都要重新编译。使得编译时间大大变长
- 影响代码复用。当我们要复用某些代码到其他项目或者其他隔离的模块时，我们发现这些代码依赖了常量类，处理方法要么是一起复制整个常量类代码过去；要么就是复制对应的常量过去，再修改代码。前者会增加无用的常量，后者则是花费了我们更多时间去做了重复性的工作。
综合以上缺点，我们的优化方法就是分割、降低常量类的代码大小，或者是将常量内聚到代码中。
解决方法有如下两种：
- 定义多种常量类，让相同作用范围的常量置于一个类中。使得代码易于维护、使得其不会过于臃肿
- 将常量定义于对应使用的类中，使其更加内聚和易于维护
全局方法
最常见的全局方法就是 Util 类了，Util 工具类出现的原因是为了抽离那些常用的操作，但是这些操作与被操作者之间又不会存在继承关系。这个时候直接抽离为工具类会更加的合理，也可使得开发效率提高。
对于工具类的定义，我们需要将工具类细化，按功能分为多种工具类，可以让代码更好维护
代码结构风格
将数据和数据操作进行分离，是一种典型的面向过程风格。而我们日常开发中的 MVC 、MVP 这类开发架构/结构，就是典型的在使用面向过程风格来编码。所以可知，面向过程并非就比面向对象要逊色，将这些风格结合，整合为最适合的，就是最好的。
