05.哪些代码设计看似是面向对象，实际是面向过程的？

哪些代码看似是面向对象，实际上是面向过程的？

1. 滥用getter、setter方法
   这种做法违反了面向对象编程的封装特性，相当于将面向对象编程风格退化成了面向过程编程风格。
   虽然我们将属性设置成为私有属性，但是提供了public的getter、setter方法，这就更将两个属性定义为public公有属性没有什么两样了。
   面向对象封装的定义是：通过访问权限控制，隐藏内部数据，外部仅能通过类提供的有限的接口访问、修改内部数据。所以，暴露不应该暴露的setter方法，明显违反了面向对象的封装特性。数据没有访问权限控制，任何代码都可以随意修改它，代码就退化成了面向过程编程风格了。
   总之，在设计实现类的时候，除非真的必要，否则不要给属性定义setter、getter方法。除此之外，尽管getter方法相对setter方法要安全些，但是如果返回的是集合容器（比如例子中的List容器），也要防范集合内部数据被修改的危险。
2. 滥用全局变量和方法
   2.1. 把所有用到的常量都集中放到一个大而全的Constants类中，并不是一个很好的设计思路。
   原因有三：
   • 这样的设计会影响代码的可维护性。
     当这个类中的常量越来越多，查找修改某个，会变得比较费时，而且会增加提交代码冲突的概率。
   • 增加代码编译时间
     当Constants类中包含很多常量定义的时候，依赖这个类的代码会很多，那每次修改Constants类，都会导致依赖它的类文件重新编译，因此会浪费很多不必要的编译时间。
   • 影响代码复用性
     如果另一个项目复用本项目某个类，而这个类由依赖Constants类，即便这个类指依赖Constants类中的一小部分常量，仍然需要把这个Constants类一并引入，也就引入了很多无关的常量到新的项目中。
     如何优化？
   • 将Constants类拆解为功能更加单一的多个类。比如更mysql配置相关的常量，放到MysqlConstants类中；跟Redis配置相关的常量，放到RedisConstants类中。
   • 并不单独定义Constants类，哪个类用到某个常量，就定义到这个类中。
     2.2. Utils类
     如果两个类用到相同的功能逻辑，为了避免代码重复，我们不应该在两个类中，将这个相同的功能逻辑，重复实现两遍。
     可以采用继承抽取父类的方式，但是如果两个类没有“兄弟”关系，采用继承会显得很别扭，影响代码可读性。
     可以考虑采用抽取工具类的方式。
     只包含静态方法不包含任何属性的Utils类，是彻彻底底的面向过程编程风格。