這是抽象類的候選人

假設我想在一個地方收集所有運動的所有常見屬性和行爲。我正在考慮將SportBase作爲抽象類用於此目的，但我不確定。我試圖理解這個例子中的抽象與接口使用之間的區別。這是抽象類的候選人

每項運動應該具有以下特性

日期時間啓動;
DateTime Ended;
字符串名稱;

如果我聲明一下這些屬性，如整數和後來我決定使用遊戲對象像遊戲StartGame分離的實體。我沒有看到明確的高抽象層次上使用的方法，以減少對修改後疼痛（這種修改可以增加新的屬性，新的行爲等）

感謝

來源

2012-11-21 user1765862

[Interface vs Base class]的可能重複（http://stackoverflow.com/questions/56867/interface-vs-base-class） –

您可以使用一個接口來提供代碼合同。

public interface ISportsEvent 
{ 
    DateTime Start { get; set; } 
    DateTime End { get; set; } 
    string Name { get; set; } 
}

但是，這並不會給你可重用實現

正如你應該更喜歡在組成繼承的一般規則。

因此，它往往不如做這樣的事情

public interface EventDetails 
{ 
    public DateTime Start { get; set; } 
    public DateTime End { get; set; } 
    public string Name { get; set; } 
} 


public class SportingEvent 
{ 

    public EventDetails Details {get;set;} 
}

現在這是一個有點粗糙，但你可以看到我在獲得。

來源

2012-11-21 21:40:52 Peter

如果你只有性能和空方法接口可能是您更好的選擇。如果你有一些實際的代碼，那麼抽象類是你唯一的選擇。還要記住，您只能繼承一個抽象類，但實現多個接口。

來源

2012-11-21 21:34:16

不，我不會這麼做。你最終會創建一個抽象的God class，它可以爲許多責任人提供方法。

來源

2012-11-21 21:36:39

我個人很可能會把它變成一個抽象類，因爲你的體育運動不僅會分享一些領域，而且他們也可能會分享一些邏輯。

接口不是用於分離重複的代碼，但它們純粹是爲了多態。

接口所做的一切都是保證你的班級將以某種方式行事。如果你打算把邏輯放在你的基類中，而不是你想要的抽象類。

來源

2012-11-21 21:37:17

這是抽象類的候選人

回答

相關問題