标签：常量 代码 之美 笔记 编译 Constants 设计 设计模式 类中

07 | 理论四：哪些代码设计看似是面向对象，实际是面向过程的？

滥用Setter，Getter

会破坏封装性

滥用全局变量和全局方法

各种Constants，Utils的滥用
拿Constants来说，过多的使用全局Constants。

首先，这样的设计会影响代码的可维护性。

如果参与开发同一个项目的工程师有很多，在开发过程中，可能都要涉及修改这个类，比如往这个类里添加常量，那这个类就会变得越来越大，成百上千行都有可能，查找修改某个常量也会变得比较费时，而且还会增加提交代码冲突的概率。

其次，这样的设计还会增加代码的编译时间。

当Constants类中包含很多常量定义的时候，依赖这个类的代码就会很多。那每次修改Constants类，都会导致依赖它的类文件重新编译，因此会浪费很多不必要的编译时间。不要小看编译花费的时间，对于一个非常大的工程项目来说，编译一次项目花费的时间可能是几分钟，甚至几十分钟。而我们在开发过程中，每次运行单元测试，都会触发一次编译的过程，这个编译时间就有可能会影响到我们的开发效率。

最后，这样的设计还会影响代码的复用性。

如果我们要在另一个项目中，复用本项目开发的某个类，而这个类又依赖Constants类。即便这个类只依赖Constants类中的一小部分常量，我们仍然需要把整个Constants类也一并引入，也就引入了很多无关的常量到新的项目中。

**那如何改进Constants类的设计呢？我这里有两种思路可以借鉴。
**
第一种是将Constants类拆解为功能更加单一的多个类，比如跟MySQL配置相关的常量，我们放到MysqlConstants类中；跟Redis配置相关的常量，我们放到RedisConstants类中。当然，还有一种我个人觉得更好的设计思路，那就是并不单独地设计Constants常量类，而是哪个类用到了某个常量，我们就把这个常量定义到这个类中。比如，RedisConfig类用到了Redis配置相关的常量，那我们就直接将这些常量定义在RedisConfig中，这样也提高了类设计的内聚性和代码的复用性。

小结

1.滥用getter、setter方法

在设计实现类的时候，除非真的需要，否则尽量不要给属性定义setter方法。除此之外，尽管getter方法相对setter方法要安全些，但是如果返回的是集合容器，那也要防范集合内部数据被修改的风险。

2.Constants类、Utils类的设计问题

对于这两种类的设计，我们尽量能做到职责单一，定义一些细化的小类，比如RedisConstants、FileUtils，而不是定义一个大而全的Constants类、Utils类。除此之外，如果能将这些类中的属性和方法，划分归并到其他业务类中，那是最好不过的了，能极大地提高类的内聚性和代码的可复用性。

3.基于贫血模型的开发模式

关于这一部分，我们只讲了为什么这种开发模式是彻彻底底的面向过程编程风格的。这是因为数据和操作是分开定义在VO/BO/Entity和Controler/Service/Repository中的。今天，你只需要掌握这一点就可以了。为什么这种开发模式如此流行？如何规避面向过程编程的弊端？有没有更好的可替代的开发模式？相关的更多问题，我们在面向对象实战篇中会一一讲解。

标签：常量,代码,之美,笔记,编译,Constants,设计,设计模式,类中
来源： https://www.cnblogs.com/wentry/p/15550067.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。