想象一下这个例子:我的一个类中有一个Set<Loan> loans
,这个Set的目的是保存用户在这个系统中的贷款历史(例如银行系统),如果这个Set是空的,它表示此用户没有任何贷款,这是我的问题:
为每个显示用户贷款状态的用户设置一个单独的布尔字段(如Boolean hasLoan;
)是一个好习惯吗?我的意思是,而不是检查Set<Loan> loans
的空虚,我检查布尔字段是真的(有贷款)和假(没有)。
关于贷款数量的相同故事:我提供了一个字段,例如loan.length
并且读取它的值,而不是调用int loanCount
字段?
每次添加或删除贷款时,我都会更新这些字段(hasLoan
和loanCount
)。我将这些字段称为“查询字段”,因为我使用它们来回答有关主要集合的查询。
答案 0 :(得分:3)
您不一定需要私人会员Boolean hasLoan
;你可以做一个吸气剂:
public boolean hasLoan() {
return !loans.isEmpty();
}
答案 1 :(得分:2)
数据隔离是OO设计的核心原则。一个方面是您应该始终避免在多个位置复制相同的数据。决定打破这种隔离的决定因素应该是重新计算该值的行为对整个系统有显着的性能影响。
在标准的Java Collection实现上调用isEmpty()
或size()
的成本可以忽略不计,因此您不应该复制这些属性的结果。
这样做的原因是代码的健壮性和可维护性。 100次中有99次,性能优化会降低代码的可维护性,因为它会引入额外的复杂性,如缓存,非直观的代码路径和反模式,破坏OO设计和隔离。次优化是可维护代码和设计的祸根和克星,应该始终避免。永远不要为了优化而优化,优化它的价值,它可以带来显着的性能提升。
答案 2 :(得分:1)
对贷款集的每次更新都应该导致更新布尔字段,这是该方法的副作用。应避免使用非显而易见的side-effects。
此外,它会导致信息冗余,从而导致更改类时出错的可能性更高或更新派生类型中的字段。
如果您正在工作,这更有效在一个团队中,你必须向每个不熟悉它的人解释一个班级的内部运作,以避免这样的错误。
答案 3 :(得分:0)
不是检查列表,而是最好使用布尔变量。 这是因为,每次你必须从数据库中获取列表数据, 然后找到列表的长度。 当然,使用布尔变量将节省额外的步骤。
此外,请确保没有数据库更新的附加源。 以免它可能使hasLoan变量未更新。