Java中的Setter约定（返回void或this）

我写Java已经快一年了，我看到了关于人们如何实现setter的两种不同约定

为了说明这一点，以下是两种约定的示例。（我也想知道这两种模式的简明名称）

使用第一个约定的类不会从其“set”方法返回任何内容。像这样：

public class Classic{
    private double _x;
    private double _y;
    public Classic(){
        x = 0;
        y = 0;
    }
    public void setX(double d){//or boolean with a type check on input
        x = d;
    }
    public void sety(double d){
        y = d;
    }
}

public class Alternative{
    private double _x;
    private double _y;
    public Alternative(){
        x = 0;
        y = 0;
    }
    public Alternative setX(double d){
        x = d;
        return(this);
    }
    public Alternative sety(double d){
        y = d;
        return(this);
    }
}

使用替代约定的类从其setter方法返回它们自己。像这样：

public class Classic{
    private double _x;
    private double _y;
    public Classic(){
        x = 0;
        y = 0;
    }
    public void setX(double d){//or boolean with a type check on input
        x = d;
    }
    public void sety(double d){
        y = d;
    }
}

public class Alternative{
    private double _x;
    private double _y;
    public Alternative(){
        x = 0;
        y = 0;
    }
    public Alternative setX(double d){
        x = d;
        return(this);
    }
    public Alternative sety(double d){
        y = d;
        return(this);
    }
}

不同之处在于替代方法语法，如

Alternative NewAlt(double x,double y){
     return(new Alternative()
                .setX(x)
                .setY(y));
}

这是可能的，而与经典设置相同的工厂方法将 像这样

Classic NewAlt(double x,double y){
     Classic temp = new Classic();
     temp.setX(x);
     temp.setY(x);
     return(temp);
}

其中哪一个更具可读性/可用性值得商榷

我的问题是关于这两种模式之间的性能差异。它存在吗？如果是的话，差异有多大，从何而来

---

如果没有性能差异，哪一个被认为是“更好的实践”？

您在类

备选方案中使用的变体是我从“构建器模式”中知道的。在那里，任务是构建一些特定的对象，类似于
builder.setX（）.setY（）.build（）

就我个人而言，只要
备选方案
变体没有具体用途，我就会使用
经典
变体

（作为旁注，我不会使用括号来表示
返回
）
在某些情况下看起来不错，但我不会过度使用它。正如在另一篇评论中提到的，它确实在构建器模式中被大量使用。在某种程度上，这可能是个人喜好的问题

在我看来，方法链接的一个缺点是调试和断点。单步执行由链式方法填充的代码可能很棘手，但这也可能取决于IDE。我发现调试的能力绝对重要，因此我通常避免在调试时使用可能使我的生活更加困难的模式和片段。
Java中的setter通常与JavaBeans的概念联系在一起，尽管我们现在使用这个概念时没有这样称呼它，但它确实经常使用，没有这样明确的命名，有时人们称之为实体（即使没有ORM上下文）

JavaBean有属性，这些属性是

关于那些二传手和传接手，除了他们应该尽可能简单之外，没有什么可说的。在这方面，setter最简单的实现是
void
one：只需设置值并退出即可

如果查看任何IDE的功能，setter的默认实现是
void
一个

在这方面，对于值对象（无论它们被称为JavaBeans、Entity、Dto等），我总是采用
void
-方式，而从不使用链接方式。当您询问最佳实践时，
void
-方式是值对象的最佳实践

对于诸如构建器、dsl、服务、流之类的工具，只有当链接真正有意义并且添加了一些东西并且不太麻烦时，我才可能使用链接

我的简短建议是，对值对象使用
void
，其余的则可以随心所欲。享受设计课程的乐趣。；）
 在java中没有“自我”。@AniketThakur确定吗？如果没有使用生成器，为什么这种情况称为
Builder pattern
？据我所知，它“只是”一个。@kpie当你把一个问题标记为Java时，请确保它是使用标准Java编译器编译的。你在这里已经有一段时间了。你知道该怎么做。这对你来说太懒了。这不是生成器模式，而是像Tom说的更流畅的API。@kpie
temp=new Classic（）温度是多少？我同意这是一个可以忽略的小缺陷，但是在其他人指出错误之前，您的代码中也存在其他错误。
Builder
模式的任务不是构建特定的对象，而是确保创建对象的整个操作一次完成，从而为任何不一致的状态留出空间。与构造函数一样，它确保在其他人开始使用之前，先用所需的值初始化对象。与构造函数不同，它使代码更具可读性，特别是在有大量参数的情况下。@bot“就像构造函数一样”，或者像工厂方法一样：D.@Tom当然，但工厂方法不一定会创建对象（它可以返回对由构造函数或另一个工厂方法初始化的现有缓存对象的引用..我们永远不会知道：P）+1用于编写易于调试的代码，但是如果您必须在setter上设置断点，您已经遇到麻烦了；-）呵呵，我完全同意。我一般都在讨论方法链接。对于二传手来说，这可能只是个人喜好的问题。我通常不会在构建器模式或类似模式之外使用它们。我很欣赏“方法链接”的答案和+1，但我真的在寻找关于性能的明确答案。或者你只是好奇……：）返回某个内容比不返回任何内容多携带一条指令（或一些额外指令），因此
返回this
稍微慢一点-如果您可以这样称呼它的话。JVM规范非常详细地介绍了它的工作原理。不幸的是，我记不太清楚了，所以请带上一撮盐。