這是工廠模式的正確用法嗎？

我的客戶端對象可以請求類Report的一組對象。定義了一組可用的報告，根據客戶的權限，不同的報告可以包含在返回的集合中。報告根據請求創建（每個客戶端在每個請求中獲取全新的報告實例）。

我應該用一種「工廠」，將封裝像下面創建報表的：

public class ReportsFactory { 

    private UserPermissionsChecker permissionsChecker; 

    public Set<Report> createReports() { 
     Set<Report> reports = new HashSet<Report>(); 
     if(permissionsChecker.hasAccessTo('report A')) { 
      reports.add(createReportA()); 
     } 
     if(permissionsChecker.hasAccessTo('report B')) { 
      reports.add(createReportB()); 
     } 
     if(permissionsChecker.hasAccessTo('report C')) { 
      reports.add(createReportC()); 
     } 
     return reports; 
    } 

    private Report createReportA() {...} 
    private Report createReportB() {...} 
    private Report createReportC() {...} 
}

就是所謂的簡單工廠模式的這種權利的使用？或者你有其他建議嗎？

**下面編輯**

一些評論說，這不正是工廠模式。如果不是，我怎麼稱呼它？

來源

2012-11-09 grafthez

我沒有看到任何問題。你懷疑你的方法有什麼具體原因嗎？ – Jesper

那些重複的「如果」部分有相同的模式：如果有資格然後創建。我想知道是否有更好的方法來封裝它，例如遵循「告訴別人」的原則。但我認爲那可能是過度工程。 – grafthez

這些'if'包含在內部。如果您添加對更多報告的支持，則不需要更改其他代碼。所以我認爲這很好。 – jgauffin

我認爲設計是正確的，但這是「工廠」一詞的錯誤用法。在工廠模式下，XxxxFactory會創建Xxxx的實例，如果需要將它們初始化，但不應用其他類型的邏輯。這裏

這種設計似乎是正確的我，但你的類寧願被稱爲ReportsService

也許UserPermissionsChecker將AuthorizationService

編輯：考慮到對單詞「服務」帳戶的批評。

目前相當普遍的（我不說普遍的）約定在Java世界，其中包括在有：通過清空所有邏輯類實現

純粹描述商業模式稱爲（也許錯誤地）POJO
所有業務邏輯主要涉及在一個名爲XxxService的類的方法中以過程樣式實現的對象Xxx。

我個人不同意這個編碼風格同意，我更喜歡object oriented programming，但不管我們喜歡還是不喜歡，這個慣例在Java EE世界的存在，並有它的連貫性。

判斷由OP提交的類的編碼風格，我推斷他遵循了這種程序方法。在這種情況下，最好遵循現有約定，並調用作爲處理Reports ReportService的過程代碼容器的類。

來源

2012-11-09 15:08:58

因此，爲了證明Factory的用法，我可以將Set 封裝到AvailableReports中，然後我會有AvailableReportsFactory？我對嗎？ – grafthez

我不相信調用一切「服務」要好得多。這是一個非常模糊的詞，幾乎沒有「經理」或「對象」更好。在域名的語言中使用單詞可能會更好。例如。它不是'hasAccessTo（）'報告的權限檢查器，也不是AuthorizationService。這是一個具有訪問權限的用戶。也許'用戶'應該有它的方法呢？ –

這有點棘手，因爲我需要某種後端ekhm ...「服務」來獲取每個請求的用戶權限。由於用戶是簡單的pojo，我無法訪問此服務。我可以將用戶獲得許可服務的方法作爲第二參數，但我想它更糟。 – grafthez

對我來說，這看起來有點builder模式，在某種意義上，你有一個對象，你建立它的數據。
這與通常返回不同具體類型的創建對象的工廠形成鮮明對比
通常，這些對象的數據構造是在具體類的CTOR中完成的，它們的對象從工廠返回。

來源

2012-11-10 14:18:19

這是工廠模式的正確用法嗎？

回答

相關問題