如何避免方法之间的依赖关系?

How can I avoid dependencies between methods?

我有以下方法:

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() 的新 class,但这也变得相当混乱.

欢迎提出想法:)

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

在其他情况下,特别是如果参数是 similar/same 类型,则使用构建器模式。不是一次指定所有参数,而是一个一个设置,最后使用 Builder 对象实例化所需的 class.

问题中有几次提到了 "messy" 代码。虽然这适用于任意代码,但设计模式 is

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

因此,如果实施得当,它要么适用于用例,要么不适用,但不应该 "messy"。我还建议您查看常用 design patterns 的 java 实现。也许,可以找到更适合问题域的替代方案。