面向对象编程时候:推荐给所有属性都加getter/setter方法,然后设置属性为私有吗?

我们知道面向对象设计项目的时候,特别是Java项目,属性一般有getter/setter方法,
但是有时候我们又是直接使用类实例的属性(直接点出)

请问下:
1、推荐给所有属性都加getter/setter方法,然后设置属性为私有吗?
2、什么场景对属性使用getter/setter,什么场景不对属性使用呢?

阅读 1.2k
avatarAI BotBETA

1. 推荐给所有属性都加getter/setter方法,然后设置属性为私有吗?

不总是推荐给所有属性都加getter/setter方法,并将属性设置为私有。

虽然这种做法在很多情况下是推荐的(尤其是在封装和隐藏内部实现细节方面),但过度使用getter/setter可能会降低代码的清晰度和简洁性,特别是在那些不需要额外逻辑(如验证、计算或懒加载)的简单属性上。

最佳实践

  • 对于需要额外逻辑的属性,如验证输入、计算值、触发事件等,应该使用getter/setter。
  • 对于简单的、不需要额外逻辑的属性,如果团队或项目规范允许,可以直接公开属性(但请注意,这可能会降低代码的封装性)。
  • 考虑使用记录类(Record Classes)(如果语言支持),如Java 14引入的Record,它提供了一种简洁的方式来创建不可变的类,其中所有字段都是私有的,并自动生成getter方法(但不提供setter方法,以保持不可变性)。

2. 什么场景对属性使用getter/setter,什么场景不对属性使用呢?

使用getter/setter的场景

  • 当需要在访问或修改属性时执行额外的逻辑,如验证输入值、记录更改、触发事件等。
  • 当需要控制对属性的访问级别,例如,你可能想公开一个属性的只读视图(仅使用getter),但不允许外部代码直接设置其值。
  • 在设计需要高封装性和可扩展性的系统中,即使当前没有额外逻辑,也可能选择添加getter/setter以便将来可能的扩展。

不使用getter/setter的场景

  • 当属性非常简单,且不需要任何额外的访问控制或逻辑时。
  • 在数据传输对象(DTOs)或简单的值对象中,这些对象通常只用于封装数据,不需要复杂的逻辑。
  • 使用记录类(如果语言支持)作为不可变数据的表示时,它们自然不包含setter方法。

总之,决定是否使用getter/setter取决于具体场景和需求。在保持代码清晰、简洁和可维护性的同时,平衡封装性和直接性是很重要的。

3 个回答
✓ 已被采纳

基于最小权利原则,推荐是将类中的属性和方法仅开放必须的权限。因此通常将属性设置为私有,并通过开放方法来选择性地提供getter或setter。

另外一个维度,基于方法去提供属性访问的能力有更好的扩展性,后期可以通过切面或直接修改方法的方式去提供额外的一些能力。

最后,从打工人的角度,getter和setter是增加代码量的。

通常,推荐将类的属性设置为私有(private),并提供相应的 getter/setter 方法 来访问和修改这些属性。这是面向对象编程中的封装(encapsulation)原则,它强调将对象的状态与其实现细节隐藏起来,只暴露必要的接口给外部.

不使用 getter/setter,直接访问属性的场景:
内部类或私有类:如果类的作用范围非常小(如仅在同一个文件中使用,或者是一个私有的嵌套类),并且你确定该类不会公开给外部使用,直接访问属性可以简化代码。

新手上路,请多包涵

个人感觉工业场景下,最好将属性设置为private,通过 getter/setter 方法访问和修改。
主要是,工业场景下,除了最小知道原则,我们还可以从这些角度理解为什么这样做:

  1. getter是读操作,setter是写操作,假如debug,我们可以分别在getter/setter处打断点,如果在字段上打断点调试,读写操作都会被追踪。显然用getter/setter粒度更细。
  2. 避免名污染。
  3. private属性可以保护属性,避免被别人肆意攻击、修改。安全性更好。
  4. 行数更多,都是工作量!😋

当然,写简单练习题、写力扣和学生时代写demo程序倒不必如此纠结。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏