2016-10-10 98 views
1

爲什麼HttpContext是抽象類而不是接口?爲什麼HttpContext是一個抽象類而不是接口?

該類是公共抽象的,所有的方法都是公共抽象的。我不明白爲什麼這個班是抽象班。

是什麼原因導致它是抽象類而不是接口?

+2

這些類型的設計問題如果沒有規範的來源很難回答,所以這主要是一種意見,除非來自ASP.NET團隊的人能夠進入並回答。也就是說,我懷疑這是因爲你不能在不破壞開發人員的接口協議的情況下向接口添加成員(向接口添加一個新成員,並且一切都停止編譯)。通過抽象類,可以添加可以選擇實現的「虛擬」成員。 ASP.NET團隊在幾個地方採用了這種模式。 – vcsjones

+1

通常抽象基類包含一些默認(即實用程序)或部分實現,子類實現可以利用,而使用接口,沒有地方「掛」的東西。這樣,「旋轉」一個定製的實現就更容易了。即使所有方法都是虛擬的,門仍然是開放的,因此它可以爲子類建立部分/輔助實現的「層」。 –

+0

@ escape-llc確實。但在這種情況下,情況並非如此。這是什麼讓我想知道... – Fred

回答

1

這是我從丹尼爾·羅斯在微軟與ASP.NET Core合作的答覆。

我相信在這種情況下,使用抽象類可以在將來的版本中添加成員,這是您無法使用接口完成的。

0

關於此主題有很多意見(例如herehere)。而且即使在ASP.NET團隊通常使用的接口,我能想到的,爲什麼他們在這種情況下選擇了一個抽象類,有幾個原因:

版本控制
我不指望HttpContext類改變很多,但抽象類的版本比接口更容易(它們實際上根本沒有版本),因爲它們可以使用關鍵字virtual部分實現。

封裝
抽象類封裝一組官能團,其中接口提供更高的合同的一個特定功能的。類只能實現一個抽象類,這對於HttpContext實現有意義,例如DefaultHttpContext

向後兼容性
雖然ASP.NET核心是ASP.NET的完全重寫,開發者習慣於對HttpContext類節目多年。這兩個班都有很多特點。


請記住,我只是猜測在這裏,也許一些ASP.NET團隊的人可以啓發我們。

相關問題