嵌套抽象和開放閉合原理

我即將實現文檔生成器。我堅持遵循開放原則，這給我帶來了一些麻煩。要求如下：嵌套抽象和開放閉合原理

會有多種文檔類型（即協議，委託書）
會有多種文檔格式（即XML，JSON，HTML，PDF）
各文檔類型需要不同的數據集是存在於該文件（即客戶的詳細資料，plenipotent細節）

由於我的選擇以下開閉原則的，我強烈希望避免使用switch語句。這意味着我需要爲特定類型的文檔和格式類型引入一些抽象和實現。

是否需要提供m x n個類的實現，其中m是文檔類型的數量，n是文檔格式的數量？我覺得這是做錯的方式。你能否給我一些提示，告訴我如何正確設計這樣的文件生成器？

2017-10-05 Dawid

我從來沒有想過總是尊重某個原則。你不應該如此專注於O/C或任何其他_guideline_，你應該專注於理解域名和基於此的設計。價值對象和適當的聚合是這裏的關鍵。 – MikeSW

你說什麼「適當的聚合」是什麼意思？你能否提供一些例子？ – Dawid

適當的聚合意味着您需要正確識別每個文檔模型，如域所示。基本上你需要用自己的約束和規則來理解每個文檔的每個細節。它與代碼，OOP，SOLID等無關。您需要了解域如何思考和接近事物，即您需要成爲領域專家，至少在此特定主題上。用域名自己的語言思考域名。看不到任何課程，功能等。 – MikeSW

由於每種格式的行爲完全不同，所以良好的設計將通過實現一個通用接口來創建不同的類，比如'IFormatter'。您可以將接口'IFormatter'注入需要調用文檔格式器的客戶端類。你可以用不同的方式來完成對象創建的責任。一個將是一個簡單的工廠方法（就我個人而言，我不是工廠方法的忠實粉絲）。另一種方式是與責任鏈。當匹配發現它會創建相應的對象時，您可以鏈接對象創建。

無論哪種方式，一旦構建客戶端類，就不需要再次修改它。如果你想將文檔格式化爲另一種格式，那麼通過實現'IFormatter'界面來創建一個新類很容易。

來源

2017-10-05 13:42:45

，我會給你一些提示

如果每個文件類型使用至少一個不同的概念，具有不同的業務限制，創建一個類爲每種類型。不要爲乾燥而流汗。唯一可重用的應該是用於封裝文檔每個細節的值對象。
Html，PDf等是導入/導出格式。充其量，與實際文檔相關的元數據。如果是很重要的，你可以有一個價值的物體，像FormattedContent其中有2個屬性：格式和內容

關於switch ..你有相當怪異的約束。但你可以使用字典，而不是開關！也許是一個抽象工廠。

來源

2017-10-05 18:04:41 MikeSW

嵌套抽象和開放閉合原理

回答

相關問題