界面應該有多複雜？

我們正在開發一個項目，其中將有一個需要由解決方案的多個部分訪問的共享配置。界面應該有多複雜？

負責Config模塊的團隊實現了一個僅由2個類組成的接口。 2個類負責獲取，緩存和提供特定值（通過屬性）。

我覺得這是一個糟糕的設計，在我看來，最好是定義可以通過接口訪問的所有配置值，但不是實現此行爲的實際類。

在我看來，對於像獲取配置值這樣的東西，給出一個接口來顯示我可以訪問的值，而不是一個類（該實現例如屬性不受控界面）。

CNC中 界面看起來是這樣的：

public interface IConfigurationResolver 
{ 
    GeneralConfiguration GetGeneralConfiguration(string Id); 
    SpecificConfiguration GetSpecificConfiguration(string Id); 
}

它是由一個類實現。我的意思是這個接口真的只是定義了兩個類，每個類都負責提供配置值，而我認爲如果接口不關心這些細節並且應該提供配置值本身，那麼它會更好。

這些是非常有經驗的開發人員，而我不是，那麼你在這方面的立場是什麼？

來源

2013-05-20 buddybubble

如果不對應用程序有更廣泛的理解，就幾乎不可能對此進行評論：大小，功能，生命週期等等。這些影響什麼的所有因素都被認爲是最佳實踐。例如，對於生命週期短的產品來說，可維護性就不那麼重要了。開發人員的努力最好花在配置類以外的其他方面。 – Khior

配置在這個項目中非常重要。這是一個將運行至少5年（可能更長）的Web應用程序。它將使用戶能夠在不同的（但非常相似的）系統上工作。這些系統將需要很多參數和公式，這些參數和公式在系統之間會有所不同，並且可能隨時間而改變。對不起，我不能真正說出我們在這裏談論的究竟是什麼 – buddybubble

之一SOLID原則是接口隔離原則「許多客戶特定的接口比一個通用接口要好。」

http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

你所說的「接口，它僅包含什麼2班「？只有兩個類實現這個接口？

我覺得這是一個不好的設計，在我看來，這將是更好的定義所有的配置值一個可以通過接口來訪問，但實現該行爲不實際類。

不知道我理解你的問題 - 是的，你應該參考接口，而不是直接的類？

來源

2013-05-20 11:31:27 DaveHogan

我認爲沒有違反這個原則，因爲在我們的例子中配置可以被看作是一個粒狀實體。分割它沒有什麼意義，因爲所有的值都可以在任何地方訪問。 – buddybubble

好的 - 夠公平的。我並不完全理解你的問題，因爲標題是界面的複雜程度，但你的問題的主體意味着你要求你提到界面而不是階級？你可以給一些關於這個問題的更多信息 – DaveHogan

我編輯了我的問題，以澄清我想問什麼:) – buddybubble

我沒有看到這種方法的任何問題。一個OO原則正在隱藏。只要類的內部結構被私有方法或子類隱藏，就根本不需要使用任何接口。

只要您想爲單行爲（如Bean Validation API）提供多個實現，或者您想要限制應該可用於類的不同用戶的方法，接口就會有意義。

來源

2013-05-20 11:36:24

有不少東西怎麼回事...

非抽象類中IConfigurationResolver接口的參考是一個代碼味道，違反了「程序的接口，而不是實現」本金（What does it mean to "program to an interface"?）。

你希望通過接口明確揭示的配置參數是一個很好的，而且是根據一個意向顯露的接口的概念（如在埃裏克Evans的Domain Driven Design討論）。

但是，如果你有很多配置值，這個接口最終可能會有很多方法。這就是你的域名的知識來源 - 將「配置世界」分解爲一組連貫的接口，每個接口用於配置應用程序的一個單獨的方面本身就是一項技能，並涉及到'我'在SOLID。 Lowy的Programming .NET components討論了合約重新分解的問題，並且作爲粗略指南建議針對每個界面3-5個方法。

我猜想「重新配置配置」的願望是在當前接口上存在兩種方法的根源。

來源

2013-05-20 13:59:36 Lawrence

界面應該有多複雜？

回答

相關問題