假設有一個在兩個層次上開發的庫：一個核心，一個低層次和一個高層次。我的設計側重於減少兩者之間的耦合。封裝枚舉或不？
其中一個高層次的例程接受枚舉（例如，FOO = 0，BAR = 1，BAZ = 2）。該枚舉由低級例程直接用於其最終目的。
爲了設計此，我有三種選擇：
您對此案有任何經驗嗎？我會選擇1，因爲它會減少耦合，但我也想聽聽你的經驗。
聽起來像是你的高層次層接受來自用戶的指令或參數，它一起傳遞低層次，而實際上並不需要知道它說什麼。
如果是這種情況，那麼選項＃3：「打破它」是一條路。
如果高層需要對命令或參數進行一些處理，並且它必須傳遞給底層，那麼很有可能在選擇之間劃分了一些界限層。各層不應該關心彼此的內部業務。
如果你確實需要這樣做，那麼分解就更加重要了，因爲你希望BOTH層依賴於枚舉，並且你希望枚舉中的一個改變迫使（至少）重新編譯雙方。 （make，dependencies等）
閱讀Dijkstra的經典論文「多程序系統的結構」，並反思它對分層哲學的看法。它位於UT Austin CS部門網站的Dijkstra檔案中。
我想這取決於你的關卡是層還是層。
如果低級模塊位於Web服務接口後面，那麼我會選擇通過爲您生成的代理代碼（當然在WCF或amsx服務的情況下）實質上實現的＃1。
如果它們是在同一個進程中運行的不同程序集，那麼我會更傾向於採用共享代碼解決方案，可能是通過創建具有核心枚舉和接口的單獨程序集。
我沒有得到太多的耦合問題。恕我直言，這兩個級別應該看到相同的枚舉（更像是選項3）。枚舉中的名字應該是高級名稱（所以誰讀它，可以理解它們，不需要理解低級名稱），其值對於高級別部分應該是不重要的。
我看到的第一個問題是更大的維護成本和更容易出錯的錯誤。就像，假設一個枚舉值改變了，或者你應該添加另一個元素。您必須記得在兩個部分中進行更改，否則，您的應用程序可能會出現意外行爲和不一致的數據。此外，您將需要一個轉換層，從而導致更多的代碼維護
希望它能幫助:)