1. 滥用 getter、setter 方法
在设计实现类的时候,除非真的需要,否则尽量不要给属性定义 setter 方法。除此之外,尽管 getter 方法相对 setter 方法要安全些,但是如果返回的是集合容器,那也要防范集合内部数据被修改的风险。
2. Constants 类、Utils 类的设计问题
对于这两种类的设计,我们尽量能做到职责单一,定义一些细化的小类,比如 RedisConstants、FileUtils,而不是定义一个大而全的 Constants 类、Utils 类。除此之外,如果能将这些类中的属性和方法,划分归并到其他业务类中,那是最好不过的了,能极大地提高类的内聚性和代码的可复用性。
3. 基于贫血模型的开发模式
这种开发模式是彻彻底底的面向过程编程风格的,这是因为数据和操作是分开定义在 VO/BO/Entity 和 Controler/Service/Repository 中的。
像 UserBo 这样,只包含数据,不包含业务逻辑的类,就叫作贫血模型(Anemic Domain Model)。同理,UserEntity、UserVo 都是基于贫血模型设计的。这种贫血模型将数据与操作分离,破坏了面向对象的封装特性,是一种典型的面向过程的编程风格。
标签:贫血,定义,面向对象,面向,设计,看似,setter From: https://www.cnblogs.com/bloodcolding/p/18120137