java - 如何避免方法之间的依赖关系？

Question

我有以下方法:

protected ArrayList<String> prepInstaller(RemoteSession session) {
    ArrayList<String> installCommand = new ArrayList<String>();
    installer.setInstallOption(getCommand());
    installer.setInstallProperties(generateInstallProperties());
    installer.setTestHome(getTestHome(session));

    switch (installer.getInstallOption()) {
    case ("addon"):
        installer.setAddOnScriptPath(getAddOnScriptPath(session, true));
        installer.setAddOnImageLocation(getAddOnPath(session, true));
        installCommand.add(installer.getInstallCommand());
        break;
    case ("install"):
        installer.setImageLocation(getImageLocation(session, true));
        installCommand.add(installer.getInstallCommand());
        break;
    case ("patch"):
    case ("rollback"):
        installer.setPatchLocationPath(getPatchPath(session, true));
        for(String currentPatch: installer.getPatches()) {
            installCommand.add(installer.getInstallCommand(currentPatch));
        }
        break;
    }

    return installCommand;
}

我的问题是这一行:

installCommand.add(installer.getInstallCommand());

包含installer.getInstallCommand()，除非运行以下命令，否则它将包含空对象:

installer.setInstallOption(getCommand());
installer.setInstallProperties(generateInstallProperties());
installer.setTestHome(getTestHome(session));

除其他外...该方法依赖于先前运行的方法，这是不可取的。我已将 installer 定义为静态工厂:

public static InstallData getInstance() {
    if (instance == null) {
        instance = new InstallData();
    }
    return instance;
}

我已经考虑过使用构建器模式，但它似乎有点笨拙。我找不到它的整洁版本。我不想使用构造函数，因为它会很困惑，而且我需要几个构造函数。

我还尝试构造一个包含所有 set 方法的对象，然后将该对象传递到一个返回 getInstallCommand() 的新类中，但这变得相当也很乱。

欢迎提出想法:)

Answer 1

正如问题中所指出的，在对象处于非法状态时实例化对象或调用方法并不是理想的行为。在大多数情况下，对象创建需要 4 个或更多参数，但其中一些参数可以有合理的默认值，可以通过需要必要的参数并替换可选参数来使用伸缩构造函数(反)模式。

在其他情况下，特别是如果参数具有相似/相同类型，则使用构建器模式。不是一次性指定所有参数，而是一一设置它们，最后使用 Builder 对象实例化所需的类。

这个问题在某些情况下提到了“困惑”的代码。虽然对于任意代码都是如此，但设计模式 is

a general reusable solution to a commonly occurring problem within a given context in software design.

因此，如果实现得当，它要么适用于用例，要么不适用，但它不应该是“困惑的”。我还建议查看常用 design patterns 的 java 实现。也许，可以找到适合问题领域的更合适的替代方案。