使用getter和setter(只获取和设置)而不是简单地为这些变量使用公共字段有什么好处?

如果getter和setter所做的不仅仅是简单的get/set,我可以很快地解决这个问题,但我不是100%清楚如何做到:

public String foo;

比:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

而前者需要的样板代码要少得多。


当前回答

除非您当前的交付需要,否则不要使用getters setter。例如,如果要更改任何内容,请不要过多考虑将来会发生什么,这是大多数生产应用程序和系统中的更改请求。

思考简单、简单,必要时增加复杂性。

我不会仅仅因为我认为这是正确的或者我喜欢这种方法,就利用对拥有深厚技术知识的企业主的无知。

我编写了一个没有getters setter的大型系统,只使用了访问修饰符和一些验证n perform-biz逻辑的方法。如果您确实需要。使用任何东西。

其他回答

我知道现在有点晚了,但我想有些人对表演感兴趣。

我做了一个性能测试。我写了一个类“NumberHolder”,它包含一个整数。您可以使用getter方法读取该IntegeranInstance.getNumber()或通过使用anInstance.number直接访问数字。我的程序通过两种方式读取数字1000000000次。该过程重复五次,并打印时间。我得到了以下结果:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(时间1是直接方式,时间2是吸气方式)

你看,吸气器(几乎)总是快一点。然后我尝试了不同次数的循环。我用了1000万和10万,而不是100万。结果:

1000万次循环:

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

1000万次循环,时间几乎相同。以下是10万(10万)个循环:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

同样,对于不同数量的循环,getter比常规方法快一点。我希望这对你有所帮助。

此外,这是为了“未来证明”你的课程。特别是,从字段更改为属性是ABI中断,因此如果您稍后决定需要更多的逻辑而不仅仅是“设置/获取字段”,那么您需要中断ABI,这当然会给针对您的类编译的任何其他内容带来问题。

我只是想补充一点,即使有时它们对于变量/对象的封装和安全是必要的,如果我们想编写一个真正的面向对象的程序,那么我们需要停止过度使用附件,因为有时我们在不真正必要的情况下非常依赖它们,这几乎与我们将变量公开一样。

我想发布一个我刚刚完成的真实世界示例:

背景-我使用休眠工具为我的数据库生成映射,这是一个我在开发时正在更改的数据库。我更改数据库模式,推送更改,然后运行hibernate工具来生成java代码。在我想向这些映射实体添加方法之前,一切都很好。如果我修改了生成的文件,则每次对数据库进行更改时都会覆盖这些文件。所以我这样扩展生成的类:

package com.foo.entities.custom
class User extends com.foo.entities.User{
     public Integer getSomething(){
         return super.getSomething();             
     }
     public void setSomething(Integer something){
         something+=1;
         super.setSomething(something); 
     }
}

我上面所做的是用我的新功能(something+1)覆盖超类上的现有方法,而不需要接触基类。如果你在一年前写了一个类,并且想在不改变基类的情况下升级到第2版(测试噩梦),也是同样的情况。希望这会有所帮助。

事实上,考虑使用访问器而不是直接公开类的字段有很多很好的理由——不仅仅是封装和使未来的更改更容易。

以下是我知道的一些原因:

与获取或设置属性相关的行为的封装-这允许以后更容易地添加附加功能(如验证)。隐藏属性的内部表示形式,同时使用替代表示形式公开属性。隔离您的公共接口不受更改的影响——允许公共接口在实现更改时保持不变,而不影响现有用户。控制属性的生存期和内存管理(处置)语义——在非托管内存环境(如C++或Objective-C)中尤为重要。在运行时为属性更改时提供调试拦截点-在某些语言中,如果没有此功能,则很难调试属性更改为特定值的时间和位置。改进了与旨在针对属性getter/setter进行操作的库的互操作性——Mocking、Serialization和WPF应运而生。允许继承者通过重写getter/setter方法来更改属性的行为和公开方式的语义。允许getter/setter作为lambda表达式而不是值传递。获取器和设置器可以允许不同的访问级别-例如,获取可以是公共的,但集合可以受到保护。