1.滥用getter、setter方法
在设计实现类的时候，除非真的需要，否则尽量不要给属性定义setter方法，因为这样会把私有字段的修改权限都暴露出去，风险较高，并且违反了封装的特性。除此之外，尽管getter方法相对setter方法要安全些，但是如果返回的是集合容器，那也要防范集合内部数据被修改的风险。
2.滥用全局变量和全局方法
这种情况在两种类的设计中比较常见，这两种类分别是Constants类和 Utils类。 对于Constants类，常常会看到开发者把程序中所有用到的常量，都集中地放到一个Constants类中。 这样的设计核心会导致到后期会增加许多无效代码的编译时间，因为当Constants类中包含很多常量定义的时候，依赖这个类的代码就会很多。那每次修改Constants类，都会导致依赖它的类文件重新编译。 对于Utils类，常常有开发者把多个类通用的数据处理逻辑（比如处理时间的逻辑）封装为静态方法放到Utils类中，这完全就是面向过程的编程思路，但这样做并不是不好，这样做可以很好地解决代码复用的问题。再次提及Utils类的设计，只是希望大家不滥用这样的方法，在设计Utils类的时候，最好也能细化一下，针对不同的功能，设计不同的Utils类，比如FileUtils、IOUtils、StringUtils、UrlUtils等，不要设计一个过于大而全的Utils类。
对于这两种类的设计，我们尽量能做到职责单一，定义一些细化的小类，比如RedisConstants、FileUtils，而不是定义一个大而全的Constants类、Utils类。除此之外，如果能将这些类中的属性和方法，划分归并到其他业务类中，那是最好不过的了，能极大地提高类的内聚性和代码的可复用性。
3.定义数据和方法分离的类——采用基于贫血模型的开发模式
最后想谈的常见的一种面向过程风格的代码，就是数据定义在一个类中，方法定义在另一个类中，而这种风格常出现在基于MVC三层结构做Web方面的后端开发中。 传统的MVC结构分为Model层、Controller层、View层这三层。不过，在做前后端分离之后，三层结构在后端开发中，会稍微有些调整，被分为Controller层、Service层、Repository层。Controller层负责暴露接口给前端调用，Service层负责核心业务逻辑，Repository层负责数据读写。而在每一层中，我们又会定义相应的VO（View Object）、BO（Business Object）、Entity。一般情况下，VO、BO、Entity中只会定义数据，不会定义方法，所有操作这些数据的业务逻辑都定义在对应的Controller类、Service类、Repository类中。这就是典型的面向过程的编程风格。基于这种风格的开发模式也被称为基于贫血模型的开发模式。
为什么这种开发模式如此流行？如何规避面向过程编程的弊端？有没有更好的可替代的开发模式？相关的更多问题，后面有时间再一起聊聊
