請求有關類設計，繼承/聚合的建議

Question

我已經開始在.NET中編寫自己的WebDAV服務器類，我開始的第一個類是WebDAVListener類，模仿HttpListener類的工作方式。

由於我不想重新實現核心http協議處理，我將使用HttpListener來實現其所有價值，因此我有一個問題。

建議的方法是什么來處理這個問題：

實現HttpListener中的所有方法和屬性，只需更改重要的類類型（即GetContext + EndGetContext方法將返回WebDAV上下文的不同類），並在內部存儲和使用HttpListener對象
通過傳遞一個HttpListener類來構造WebDAVListener來使用？
使用接口為HttpListener創建一個包裝器，並通過傳遞一個實現此接口的對象來構造WebDAVListener？

如果將HttpListener（偽裝的或其他）傳遞給WebDAVListener的路徑，是否會通過屬性公開底層偵聽器對象，或者您希望使用該類的程序保持對底層HttpListener的引用？

此外，在這種情況下，您是否會通過WebDAVListener公開HttpListener一些方法，比如Start和Stop，或者您是否會再次期望使用它的程序保留HttpListener參考所有這些東西？

我最初的反應告訴我，我想要一個組合。 首先，我希望我的WebDAVListener類看起來像一個完整的實現，隱藏在它下面有一個HttpListener對象的事實。

另一方面，我想構建單元測試而不實際啟動網絡服務器，所以某種類型的模擬能力也很好，這表明我想要接口包裝方式。

我可以解決這個問題的一種方法是：

public WebDAVListener()
    : WebDAVListener(new HttpListenerWrapper())
{
}

public WebDAVListener(IHttpListenerWrapper listener)
{
}

然后我將在我自己的類中實現HttpListener的所有方法（至少所有那些有意義的方法），主要是將鏈接調用到底層的HttpListener對象。

你怎么看？

最后一個問題：如果我采用接口的方式，假設接口將1對1映射到HttpListener類，並且只是為了添加對mocking的支持而編寫，那么這樣的接口稱為包裝器還是適配器？

Answer 1

我將首先回答你的上一個問題：如果一個類使用匹配某個ISource的包含對象實現一些ITarget接口，那么它就是一個適配器 - 一個從ISource到ITarget的適配器。 在這種情況下，沒有源接口，你試圖添加一個，所以我稱之為包裝器。

我傾向於

創建一個WebDavListener類，它具有它自己的行為所需的所有方法，在內部使用HttpListener，並且不公開有關該HttpListener的任何內容。
如果需要 ，可以按照建議制作IHttpListenerWrapper和HttpListenerWrapper，並更改WebDavListener以在其構造函數中使用IHttpListenerWrapper。 假設所有方法都相同，這應該是一個簡單的搜索和替換。 您甚至可以將原始構造函數保留在那里並讓它構造一個包裝器並調用新的構造函數。
如果您需要它 ，請為它實現一個IWebDavListener，如果您認為您可能需要一個虛擬WebDAV監聽器來進行其他事情的單元測試。

這種設計問題就是為什么我喜歡像ReSharper這樣的重構工具：Extract Interface，Create Derived Implementation等。讓這些更改變得更容易，所以你現在或以后都可以不用擔心:-)（當然，假設您可以在以后自由更改源，這取決於您提供的內容。）