Java 按类字段、重写的类方法或属性传递参数

我最近在想，下面介绍的三种向方法传递参数的方法中，哪一种最适合您、您的CPU、内存，为什么。我正在考虑的方法允许我在将来传递更多参数，而不改变方法签名

如果你知道一些更好的事情，我会在这里聆听和学习

传递方法 Params.java 使命感 接收

---

按类传递字段 Params.java 呼叫和接收 这里没有魔法，只需创建一个新的Params对象，使用setter，将其传递给方法并使用getter

---

传递属性类 使命感 接收

---

我很高兴展示了一个真实的代码示例，它实际上需要传递不同类型和数量的属性。我使用第三种方法-通过属性传递：

public interface DataProvider {
    public String getContent(Properties properties);
}

public class HttpProvider implements DataProvider {
    @Override
    public String getContent(Properties properties) {
        InputStream in = new URL(properties.get("URL")).openStream();
        String content = IOUtils.toString(in);
        IOUtils.closeQuietly(in);
        return content;
    }

public class FtpProvider implements DataProvider {
    @Override
    public String getContent(Properties properties) {
        FTPClient ftpClient = new FTPClient();
        ftpClient.connect(properties.get("server"), properties.get("port"));
        ftpClient.login(properties.get("user"), properties.get("pass"));
        // Get file stream and save the content to a variable here
        return content;
    }
}

---

一个用于获取文件的不同方法的接口。我并不坚持这是好是坏，这只是我在当前工作项目中偶然发现的一个代码示例，我想知道是否可以做得更好。

接口中的签名永远不会改变！！！如果您打算将来更改API（即更改、添加或删除参数），一种可接受的方法可能是将您的参数增加到对象中，以避免破坏签名。

在性能上，“Params”类的使用优于属性。java编译器可以很好地处理此类短期类

• 可以看到一些构造函数/工厂方法的属性，比如XML之类的
• 在更大的系统中可以看到一个包含类的参数，以使API仅限于一个参数，而不使用重载方法

我会：

public class Params {
    public final int a;
    public final int b;

    public Params(int a, int b) {
        this.a = a;
        this.b = b;
    }
}

并在课堂上立即使用

params.a

---

对于其余部分，还有构建器模式，但这更像是复杂构造函数的替代品。

取决于您正在做什么。在许多情况下，所有这些想法都是不好的。@Kayaman为什么不好？有时候你不想或者不能在一个方法中传递所有的参数，当然不是。例如，您可能需要在必要时传递一个

Map

。然而，我相信你认为这比实际情况更为必要。您在不修改方法签名的情况下传递更多参数的想法不太合理。如果您想让额外的参数做任何事情，您必须修改该方法。更不用说您将丢失强类型，因此您不知道是否传递了正确的类型和数量的参数。如果你有一个特定的案例，你认为你的想法是必要的，编辑你的帖子来展示这一点。可能有一个很好的解决方案。@Kayaman我已经编辑了我的问题，并添加了我当前项目中的示例代码。请查看并让我知道您的想法。更好的解决方案是让提供者在其构造函数中获取所需的参数。那么您的

getContent（）

甚至不需要任何参数。是的，我知道，我已经指出：“我正在考虑一些方法，这些方法允许我在未来传递更多参数，而不改变方法签名。”。请注意，参数（或您拥有的参数数量）是您的方法签名的一部分，请小心；-）@itachi你考虑的是糟糕的设计。然而，如果你真的认为你在这里想出了一个聪明的主意，只要把每一种方法都纳入

Map

。你将能够通过几乎任何你想要的，最终你会意识到为什么这是一个坏主意开始。你已经被警告了。

public void foo(Params p) {
    int p1 = p.getParamOne();
    int p2 = p.getParamTwo();
}

public class Params {
    private int paramOne;
    private int paramTwo;

    // Getters and setters here
}

properties.put("paramOne", 1);
properties.put("paramTwo", 2);
obj.foo(properties);

public void foo(Properties properties) {
    int a = (int) properties.get("paramOne");
    int b = (int) properties.get("paramTwo");
}

public interface DataProvider {
    public String getContent(Properties properties);
}

public class HttpProvider implements DataProvider {
    @Override
    public String getContent(Properties properties) {
        InputStream in = new URL(properties.get("URL")).openStream();
        String content = IOUtils.toString(in);
        IOUtils.closeQuietly(in);
        return content;
    }

public class FtpProvider implements DataProvider {
    @Override
    public String getContent(Properties properties) {
        FTPClient ftpClient = new FTPClient();
        ftpClient.connect(properties.get("server"), properties.get("port"));
        ftpClient.login(properties.get("user"), properties.get("pass"));
        // Get file stream and save the content to a variable here
        return content;
    }
}

public class Params {
    public final int a;
    public final int b;

    public Params(int a, int b) {
        this.a = a;
        this.b = b;
    }
}