2015-09-09 66 views
0

我有以下方法:如何避免方法之間的依賴關係?

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()的新類,但這樣也變得相當混亂。

想法表示歡迎:)

+1

似乎'installer'已經是某種'Builder'了。您可以通過擁有一些有意義的整體對象來整理事情(將高度內聚的數據分組爲單個概念),但我不知道您的域足以提出這樣的分組。還有,像String命令= new InstallCommandBuilder(installOptions,installProperties,testHome).forAddon(scriptPath,imagePath).build();' – plalx

+0

謝謝 - 這就是我最終做的 - 我使用了InstallCommandBuilder。 – eeijlar

回答

1

因爲它是在提問時指出,它不是一個對象實例化或當物體處於非法狀態被稱爲一個方法的期望的行爲。在大多數情況下,對象創建需要4個或更多的參數,但其中一些可以有合理的默認值,可以通過要求必要的參數並替換可選參數來使用伸縮構造函數(反)模式。

在其他情況下,特別是如果參數類似/相同類型,則使用生成器模式。不是一次指定所有參數,而是逐個設置它們,最後使用Builder對象實例化所需的類。

這個問題幾次提到「凌亂」的代碼。雖然這是事實的任意代碼,設計模式is

一般可重複使用的解決方案,一個經常發生的問題,在軟件設計 給定的範圍內。

因此,如果正確實施,它可以爲用例工作,也可以不工作,但不應該是「雜亂」。我還建議看看常用的design patterns的java實現。也許,可以找到適合問題領域的更合適的替代方案。

+0

從github鏈接的設計模式非常好 - 非常感謝。建設者模式的實施有非常好的。 – eeijlar