如何為邏輯完全不同的多種策略實現一種方法？

Question

我覺得很難給這個問題一個具體的標題，因為我不太了解如何命名我的問題類型。 任何建議歡迎。

我有一個運行邏輯的服務，該邏輯實際上執行相同的操作（例如，保存縮略圖），但是對於不同的提供程序包含完全不同的邏輯：

@Service
public class ThumbnailService {
    public void saveForProvider1(Prov1 url) {

    }

    public void saveForProvider2(Prov2 url) {
        //completely different logic than Provider1; also a different parameter Object "Prov2"
    }
}

問題1 ：對於任何新的provider我都必須在ThumbnailService創建其他方法。

現在在特定點上，我想異步運行這些方法：

//basically just an async wrapper service
@Service
@Async
public class ThumbnailServiceAsync {
    @Autowired
    private ThumbnailService delegator;

    public class asyncSaveForProvider1(Prov1 url) { 
        delegator.saveForProvider1(url);
    }

    public class asyncSaveForProvider2(Prov2 url) { 
        delegator.saveForProvider2(url);
    }
}

通過Integer變量切換，在該變量中我知道哪個數字代表哪個提供程序：

int provider;
switch (provider) {
    case 1: thumbServiceAsync.asyncSaveForProvider1(url); break;
    case 2: thumbServiceAsync.asyncSaveForProvider2(url); break;
    default: throw NotSupportedException();
}

問題2 ：如您所見，我只是為了委托給特定的提供程序例程而編寫了許多代碼。 在介紹任何其他提供程序時，我還必須至少觸摸提到的這三個類。

問題：如何優化此過程？ 特別是考慮到到那時，可以實施更多的提供商。 而且，不僅是縮略圖例程，而且還必須為每個提供者實施更高級的方法，但它們的邏輯有所不同。 如“為providerX創建用戶”，或“為providerX運行一些清理例程”。

Answer 1

interface Provider {
   void specificProviderCode();
}

public class Provider1 implements Provider {
   public void specificProviderCode(){

   }
}

public class ProviderFactory{
   public static Provider createProvider(ProviderType providerType){
      if(providerType.equals(ProviderType.TYPE_1){
         return new Provider1();
      }
   }
}

@Service
public class ThumbnailService {
   public void saveForProvider(Provider provider){
       provider.specificProviderCode();
   }
}

@Service
@Async
public class ThumbnailServiceAsync {
    @Autowired
    private ThumbnailService delegator;

    public class asyncSaveForProvider(ProviderType providerType) {
        Provider url = ProviderFactory.createprovider(providerType); 
        delegator.saveForProvider(url);
    }
}

現在，僅在此處添加新的提供程序時，您需要進行更改（以使用特定的邏輯創建新的提供程序），這兩個服務都將不會更改，這也意味着服務的所有調用者都不需要更改其代碼。

Answer 2

命令模式非常適合這里。

將save方法視為Runnable或Callable的實例（Java中的基本Command接口）。 如果ThumbnailService將每個唯一的save方法及其唯一參數包裝到這些Command接口之一中，則ThumbnailServiceAsync可能會成為一個簡單的Executor ，而無需Providers知識。 switch語句消失了，因為執行器將每個命令都視為相同：通過調用run()或call() 。

這就剩下關閉ThumbnailService的問題了。 我們也希望從該類中消除對具體Providers了解。 顯而易見的OOP方法是將不同的邏輯分解為單獨的類，有可能分解為Providers本身。 如果必須在提供者周圍包裝一個公共接口，則可能需要訴諸序列化不同的參數，例如字符串，轉換或使用反射。