关于java类的set方法，可不可以返回this？

[七个披萨]

请问，有谁知道java类的set方法，为什么不返回this呢？如果返回当前对象，在构造对象的时候，感觉会更方便一些。
或者，换句话说，java类的set方法，可不可以返回当前对象？另外自己最近也尝试了返回this，但是发现有时会影响程序运行成功，想不明白是为什么。
比如下面这段代码，一开始set方法返回了this，但是报错了，改成void就好了

@Component
@ConfigurationProperties(prefix = "practice")
public class OrderProperties {

    //这里属性的名字，必须要和配置文件里的一致
    private ItemProperties item = new ItemProperties();

    public ItemProperties getItemProperties() {
        return item;
    }

    public void setItem(ItemProperties item) {
        this.item = item;
    }
}

[qq_39936465]

如果你的代码是一个一个敲出来的就当我没说吧。

[七个披萨]

引用 20 楼 qq_39936465 的回复:

[quote=引用 18 楼 七个披萨 的回复:] [quote=引用 17 楼 qq_39936465 的回复:] [quote=引用 16 楼 maradona1984 的回复:] 你这话说的...java程序员需要辨别this是哪个this?这又不是js,没那么多门门道道,而且就算是js,作为js流传最广的库jquery,大部分方法都返回了jquery对象,所以你可以不断的调用jquery的方法,这种风格的代码一般就是用于设置参数较多的场景,的确能提升一些敲代码的连贯性

set和get本身不是被用来一个一个赋值用的，要方便为什么不直接在构造方法里全部一下输入呢，还省的你打set，楼主本身就是有强迫症的人一定要一个一个set。总之并不比直接在构造方法里输入参数节省多少代码，只是满足楼主个人喜好，并不值得推广。[/quote] 实体的字段多的时候，构造方法是非常不好用的。你大概没接触过字段很多，但是初始化对象的时候只需要set其中几个字段或一个字段。我有这个想法，也不是凭空而来，是我写代码的时候，发现java提供的很多java类允许链式赋值，比如StringBuilder的append就能一直不换行append[/quote] 现在都有编程工具，你要说代码能少打其实也没多花多少力气，而且你的方法不适用于所有情况，不值得推广。而且不返回this看起来也很方便一样也很整齐。[/quote] 是的，我知道会出问题。正是因为我知道不适用，所以才来问的，想知道为什么会不行。我贴出来的例子，正是出问题的一个例子。我之所以纠结这个问题，主要不是为了少写代码，因为写代码真的不费什么劲，而是为了让代码看起来更简洁的同时可读性也更高。 但是无论如何，还是谢谢你

[七个披萨]

现在我不纠结这个问题了。当初之所以想问，是因为我想这么用，但是身边没人这么用，没有在网上找到相关的问题和回答，加上做例子的时候还因为这个return this出错了，所以想来咨询一下为什么出错，return this到底可不可行，如果不可行，为什么会不可行。 但是现在我打算先把问题放一放，等以后基础更扎实了，知识面更广了，也许我就搞明白了。

[maradona1984]

引用 17 楼 qq_39936465 的回复:

[quote=引用 16 楼 maradona1984 的回复:]

你这话说的...java程序员需要辨别this是哪个this?这又不是js,没那么多门门道道,而且就算是js,作为js流传最广的库jquery,大部分方法都返回了jquery对象,所以你可以不断的调用jquery的方法,这种风格的代码一般就是用于设置参数较多的场景,的确能提升一些敲代码的连贯性

set和get本身不是被用来一个一个赋值用的，要方便为什么不直接在构造方法里全部一下输入呢，还省的你打set，楼主本身就是有强迫症的人一定要一个一个set。总之并不比直接在构造方法里输入参数节省多少代码，只是满足楼主个人喜好，并不值得推广。[/quote]
说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的
构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量
这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名

当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

[我是程序员 .]

不建议返回this，this只是针对当前对象，如果在多个类中多次出现this，最终又返回this，系统识别不了是哪个this，个人愚见，希望对你有帮助

[qq_39936465]

引用 26 楼 maradona1984 的回复:

[quote=引用 25 楼 qq_39936465 的回复:] [quote=引用 24 楼 maradona1984 的回复:] 说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的 构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量 这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名 当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

因为set 返回this，如果该类是内部类话还能理解，但是一般这种类都是外部类，这个this可以说是隐形的，所以说对程序的可读性会变差，一个是浪费时间读程序，一个是浪费时间写程序。我始终认为代码写的严谨点，比代码写的简单点要好。越是简单的代码可读性越差，代码命令简洁并不能使程序提高多少速度，关键还是看算法和程序结构。越是java这种开放性代码就越应该方便其他人阅读理解程序。[/quote] 这个我完全没get到你的点,java的this无论在哪都非常好理解啊,setter方法里不也有this.xxx=xxx么,后面再加个return this就让你无法理解this的含义?按照代码运行的顺序,上一行都看不懂了,何必看下一行? 或许你想说内部类调用外部类的属性?但这跟可读性有啥关系啊?完全不知所云了,这个跟你说的东西都搭不上边,为啥强加一些可读性的锅在他头上,那为啥java要搞lambda,为啥要搞类型推断,为啥要不断整新的语法糖,按照你的逻辑,这种东西都是异端咯?一个箭头指向一个方法可比写个匿名类难理解多了,为啥要搞出这种语法来? 更何况这种写法可读性并不差,如果这都不能一眼看出this代表的意义,这水平连入门都没有吧,还看啥别人源码,老老实实先把java语法学好不行?[/quote] 我跟你说什么好，1个类变量问题不大，2个，3个相同的类变量呢？

                 .setOrderId("ddddddd");

        order.setOrderId("ddddddd");

你说看到上面2句程序那个理解更快？ 如果你说我只在构造使用，那么build方法也能实现上面效果，就是前面加类变量名的话也没加大多少工作量。 lambde 技术并不成熟，看清起来简洁，但是出现问题排查起来更难。

引用 楼主 七个披萨 的回复:

请问，有谁知道java类的set方法，为什么不返回this呢？如果返回当前对象，在构造对象的时候，感觉会更方便一些。 或者，换句话说，java类的set方法，可不可以返回当前对象？另外自己最近也尝试了返回this，但是发现有时会影响程序运行成功，想不明白是为什么。 比如下面这段代码，一开始set方法返回了this，但是报错了，改成void就好了

@Component
@ConfigurationProperties(prefix = "practice")
public class OrderProperties {

    //这里属性的名字，必须要和配置文件里的一致
    private ItemProperties item = new ItemProperties();

    public ItemProperties getItemProperties() {
        return item;
    }

    public void setItem(ItemProperties item) {
        this.item = item;
    }
}

推荐你看一下国外程序员对此的评价，褒贬不一。 http://www.itdaan.com/blog/2009/08/28/86ce4ec17b65617e696c41eec2323ba7.html

[七个披萨]

引用 27 楼 qq_39936465 的回复:

[quote=引用 26 楼 maradona1984 的回复:] [quote=引用 25 楼 qq_39936465 的回复:] [quote=引用 24 楼 maradona1984 的回复:] 说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的 构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量 这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名 当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

因为set 返回this，如果该类是内部类话还能理解，但是一般这种类都是外部类，这个this可以说是隐形的，所以说对程序的可读性会变差，一个是浪费时间读程序，一个是浪费时间写程序。我始终认为代码写的严谨点，比代码写的简单点要好。越是简单的代码可读性越差，代码命令简洁并不能使程序提高多少速度，关键还是看算法和程序结构。越是java这种开放性代码就越应该方便其他人阅读理解程序。[/quote] 这个我完全没get到你的点,java的this无论在哪都非常好理解啊,setter方法里不也有this.xxx=xxx么,后面再加个return this就让你无法理解this的含义?按照代码运行的顺序,上一行都看不懂了,何必看下一行? 或许你想说内部类调用外部类的属性?但这跟可读性有啥关系啊?完全不知所云了,这个跟你说的东西都搭不上边,为啥强加一些可读性的锅在他头上,那为啥java要搞lambda,为啥要搞类型推断,为啥要不断整新的语法糖,按照你的逻辑,这种东西都是异端咯?一个箭头指向一个方法可比写个匿名类难理解多了,为啥要搞出这种语法来? 更何况这种写法可读性并不差,如果这都不能一眼看出this代表的意义,这水平连入门都没有吧,还看啥别人源码,老老实实先把java语法学好不行?[/quote] 我跟你说什么好，1个类变量问题不大，2个，3个相同的类变量呢？

                 .setOrderId("ddddddd");

        order.setOrderId("ddddddd");

你说看到上面2句程序那个理解更快？ 如果你说我只在构造使用，那么build方法也能实现上面效果，就是前面加类变量名的话也没加大多少工作量。 lambde 技术并不成熟，看清起来简洁，但是出现问题排查起来更难。

引用 楼主 七个披萨 的回复:

请问，有谁知道java类的set方法，为什么不返回this呢？如果返回当前对象，在构造对象的时候，感觉会更方便一些。 或者，换句话说，java类的set方法，可不可以返回当前对象？另外自己最近也尝试了返回this，但是发现有时会影响程序运行成功，想不明白是为什么。 比如下面这段代码，一开始set方法返回了this，但是报错了，改成void就好了

@Component
@ConfigurationProperties(prefix = "practice")
public class OrderProperties {

    //这里属性的名字，必须要和配置文件里的一致
    private ItemProperties item = new ItemProperties();

    public ItemProperties getItemProperties() {
        return item;
    }

    public void setItem(ItemProperties item) {
        this.item = item;
    }
}

推荐你看一下国外程序员对此的评价，褒贬不一。 http://www.itdaan.com/blog/2009/08/28/86ce4ec17b65617e696c41eec2323ba7.html[/quote] 虽然并不是很赞同你的说法，但是你贴出来的帖子很不错。我想我大概知道该怎么做比较好了。 传统的set方法可以不改变，如果想要做成链式的风格，就另外写一个方法。比如下面这个，我觉得就很好

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

[maradona1984]

引用 27 楼 qq_39936465 的回复:

[quote=引用 26 楼 maradona1984 的回复:]
[quote=引用 25 楼 qq_39936465 的回复:]
[quote=引用 24 楼 maradona1984 的回复:]

说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的
构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量
这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名

当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

因为set 返回this，如果该类是内部类话还能理解，但是一般这种类都是外部类，这个this可以说是隐形的，所以说对程序的可读性会变差，一个是浪费时间读程序，一个是浪费时间写程序。我始终认为代码写的严谨点，比代码写的简单点要好。越是简单的代码可读性越差，代码命令简洁并不能使程序提高多少速度，关键还是看算法和程序结构。越是java这种开放性代码就越应该方便其他人阅读理解程序。[/quote]
这个我完全没get到你的点,java的this无论在哪都非常好理解啊,setter方法里不也有this.xxx=xxx么,后面再加个return this就让你无法理解this的含义?按照代码运行的顺序,上一行都看不懂了,何必看下一行?
或许你想说内部类调用外部类的属性?但这跟可读性有啥关系啊?完全不知所云了,这个跟你说的东西都搭不上边,为啥强加一些可读性的锅在他头上,那为啥java要搞lambda,为啥要搞类型推断,为啥要不断整新的语法糖,按照你的逻辑,这种东西都是异端咯?一个箭头指向一个方法可比写个匿名类难理解多了,为啥要搞出这种语法来?
更何况这种写法可读性并不差,如果这都不能一眼看出this代表的意义,这水平连入门都没有吧,还看啥别人源码,老老实实先把java语法学好不行?[/quote]

我跟你说什么好，1个类变量问题不大，2个，3个相同的类变量呢？

                 .setOrderId("ddddddd");

        order.setOrderId("ddddddd");

你说看到上面2句程序那个理解更快？

如果你说我只在构造使用，那么build方法也能实现上面效果，就是前面加类变量名的话也没加大多少工作量。
lambde 技术并不成熟，看清起来简洁，但是出现问题排查起来更难。

引用 楼主 七个披萨 的回复:

请问，有谁知道java类的set方法，为什么不返回this呢？如果返回当前对象，在构造对象的时候，感觉会更方便一些。
或者，换句话说，java类的set方法，可不可以返回当前对象？另外自己最近也尝试了返回this，但是发现有时会影响程序运行成功，想不明白是为什么。
比如下面这段代码，一开始set方法返回了this，但是报错了，改成void就好了

@Component
@ConfigurationProperties(prefix = "practice")
public class OrderProperties {

    //这里属性的名字，必须要和配置文件里的一致
    private ItemProperties item = new ItemProperties();

    public ItemProperties getItemProperties() {
        return item;
    }

    public void setItem(ItemProperties item) {
        this.item = item;
    }
}

推荐你看一下国外程序员对此的评价，褒贬不一。

http://www.itdaan.com/blog/2009/08/28/86ce4ec17b65617e696c41eec2323ba7.html[/quote]
褒大于贬,而且说了这种风格的代码本就适用于多个属性setter,很连贯,的确能解决一些问题,楼主举的例子就是很好的应用场景
而且你说的可读性问题纯粹是强词夺理罢了,这么简单不存在业务逻辑的样板代码,怎么会存在可读性问题
这种风格跟java主流的不一致,但并不是不好的设计,毕竟其他语言大量使用
你说的报错大概跟spring有关,但不是这种风格代码的错误

[七个披萨]

引用 29 楼 maradona1984 的回复:

[quote=引用 27 楼 qq_39936465 的回复:] [quote=引用 26 楼 maradona1984 的回复:] [quote=引用 25 楼 qq_39936465 的回复:] [quote=引用 24 楼 maradona1984 的回复:] 说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的 构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量 这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名 当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

因为set 返回this，如果该类是内部类话还能理解，但是一般这种类都是外部类，这个this可以说是隐形的，所以说对程序的可读性会变差，一个是浪费时间读程序，一个是浪费时间写程序。我始终认为代码写的严谨点，比代码写的简单点要好。越是简单的代码可读性越差，代码命令简洁并不能使程序提高多少速度，关键还是看算法和程序结构。越是java这种开放性代码就越应该方便其他人阅读理解程序。[/quote] 这个我完全没get到你的点,java的this无论在哪都非常好理解啊,setter方法里不也有this.xxx=xxx么,后面再加个return this就让你无法理解this的含义?按照代码运行的顺序,上一行都看不懂了,何必看下一行? 或许你想说内部类调用外部类的属性?但这跟可读性有啥关系啊?完全不知所云了,这个跟你说的东西都搭不上边,为啥强加一些可读性的锅在他头上,那为啥java要搞lambda,为啥要搞类型推断,为啥要不断整新的语法糖,按照你的逻辑,这种东西都是异端咯?一个箭头指向一个方法可比写个匿名类难理解多了,为啥要搞出这种语法来? 更何况这种写法可读性并不差,如果这都不能一眼看出this代表的意义,这水平连入门都没有吧,还看啥别人源码,老老实实先把java语法学好不行?[/quote] 我跟你说什么好，1个类变量问题不大，2个，3个相同的类变量呢？

                 .setOrderId("ddddddd");

        order.setOrderId("ddddddd");

你说看到上面2句程序那个理解更快？ 如果你说我只在构造使用，那么build方法也能实现上面效果，就是前面加类变量名的话也没加大多少工作量。 lambde 技术并不成熟，看清起来简洁，但是出现问题排查起来更难。

引用 楼主 七个披萨 的回复:

请问，有谁知道java类的set方法，为什么不返回this呢？如果返回当前对象，在构造对象的时候，感觉会更方便一些。 或者，换句话说，java类的set方法，可不可以返回当前对象？另外自己最近也尝试了返回this，但是发现有时会影响程序运行成功，想不明白是为什么。 比如下面这段代码，一开始set方法返回了this，但是报错了，改成void就好了

@Component
@ConfigurationProperties(prefix = "practice")
public class OrderProperties {

    //这里属性的名字，必须要和配置文件里的一致
    private ItemProperties item = new ItemProperties();

    public ItemProperties getItemProperties() {
        return item;
    }

    public void setItem(ItemProperties item) {
        this.item = item;
    }
}

推荐你看一下国外程序员对此的评价，褒贬不一。 http://www.itdaan.com/blog/2009/08/28/86ce4ec17b65617e696c41eec2323ba7.html[/quote] 褒大于贬,而且说了这种风格的代码本就适用于多个属性setter,很连贯,的确能解决一些问题,楼主举的例子就是很好的应用场景 而且你说的可读性问题纯粹是强词夺理罢了,这么简单不存在业务逻辑的样板代码,怎么会存在可读性问题 这种风格跟java主流的不一致,但并不是不好的设计,毕竟其他语言大量使用 你说的报错大概跟spring有关,但不是这种风格代码的错误[/quote] 对，应该就是他贴出来的帖子里提到的，可能不兼容spring，不过帖子里也有人给出了很好解决办法，这样无论是哪种编程方式，都能照顾到了

[七个披萨]

本来都放弃了，结果网友贴出来的帖子，一下子解决了我所有的问题。 帖子地址 关于我提到的报错问题，十有八九是spring的兼容问题。 解决方式：

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

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

一开始是我有点死脑筋了，不懂得拐弯。不过也还好来问了，要不到现在也想不明白为什么会出错

[echso。。]

set方法不是void的吗？不是没有返回值吗

[qq_39936465]

引用 24 楼 maradona1984 的回复:

说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的
构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量
这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名

当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

因为set 返回this，如果该类是内部类话还能理解，但是一般这种类都是外部类，这个this可以说是隐形的，所以说对程序的可读性会变差，一个是浪费时间读程序，一个是浪费时间写程序。我始终认为代码写的严谨点，比代码写的简单点要好。越是简单的代码可读性越差，代码命令简洁并不能使程序提高多少速度，关键还是看算法和程序结构。越是java这种开放性代码就越应该方便其他人阅读理解程序。

[七个披萨]

引用 32 楼 weixin_44729898 的回复:

set方法不是void的吗？不是没有返回值吗

没人规定set方法必须是void，你可以让set方法做任何事，也能返回值。默认的set方法没有返回值，是因为Javabean的规范就是这样 http://www.itdaan.com/blog/2009/08/28/86ce4ec17b65617e696c41eec2323ba7.html

[maradona1984]

引用 25 楼 qq_39936465 的回复:

[quote=引用 24 楼 maradona1984 的回复:]

说了这是种风格,其他语言里很多类似的写法,java里也有,并不存在好与不好的
构造方法里少数字段倒是可以整,但是多了怎么办?很多代码检查工具直接会检查出超过5个形参的方法的,建议修改,因为普通人很难将参数一一对应起来,而且参数一多,穷举所有可能的参数组合是不可能的,你不可避免的要去设置一些你不关心的参数,增加工作量
这种方式,比传统的setter方法要好的一个点就是不需要重新新起一行,用对象名.方法名这种方式去setter,你手不需要离开键盘,也不需要复制/重新敲一遍对象名

当然这个只是个小问题,也并不会有多大的好处和坏处,但我只是说这是一种代码风格,无论java还是其他语言都是很常见的

因为set 返回this，如果该类是内部类话还能理解，但是一般这种类都是外部类，这个this可以说是隐形的，所以说对程序的可读性会变差，一个是浪费时间读程序，一个是浪费时间写程序。我始终认为代码写的严谨点，比代码写的简单点要好。越是简单的代码可读性越差，代码命令简洁并不能使程序提高多少速度，关键还是看算法和程序结构。越是java这种开放性代码就越应该方便其他人阅读理解程序。[/quote]
这个我完全没get到你的点,java的this无论在哪都非常好理解啊,setter方法里不也有this.xxx=xxx么,后面再加个return this就让你无法理解this的含义?按照代码运行的顺序,上一行都看不懂了,何必看下一行?
或许你想说内部类调用外部类的属性?但这跟可读性有啥关系啊?完全不知所云了,这个跟你说的东西都搭不上边,为啥强加一些可读性的锅在他头上,那为啥java要搞lambda,为啥要搞类型推断,为啥要不断整新的语法糖,按照你的逻辑,这种东西都是异端咯?一个箭头指向一个方法可比写个匿名类难理解多了,为啥要搞出这种语法来?
更何况这种写法可读性并不差,如果这都不能一眼看出this代表的意义,这水平连入门都没有吧,还看啥别人源码,老老实实先把java语法学好不行?

[mr_foxsand]

你这样更难读懂了！set方法是为了给类的全局属性赋值！自己指向自己的意义何在？

[七个披萨]

引用 34 楼 mr_foxsand 的回复:

你这样更难读懂了！set方法是为了给类的全局属性赋值！自己指向自己的意义何在？

http://www.itdaan.com/blog/2009/08/28/86ce4ec17b65617e696c41eec2323ba7.html

[Guijun626]

因为JDK中获取类属性的set方法的判断是

[Guijun626]

在JDK的 Introspector 类中

[MC阿甘]

我觉得可能出现的问题是比如某些框架无法识别带返回值的setter，比如spring或者mybatis（事实上这两个都可以识别）

[玉让]

引用 4 楼 七个披萨 的回复:

[quote=引用 3 楼 black8angel 的回复:] 非得要返回this也可以啊 public OrderProperties setItem(ItemProperties item) { this.item = item; return this； } 继续测试继续理解

请问，有不建议返回this的情况吗？之所以会有这个疑问，是因为我做样例的时候，发现返回了this反而出问题（就是上面那段代码），不知道是什么原理，请问这是为什么啊？[/quote] 单个对象这样没问题，可以return this；如果有父子关系，父类实例pobj和子类实例cobj两个，则代码："pobj.set父类属性().set子类属性();"会报错