基類實現接口

Question

1. 基類實現接口的缺點/風險是什么？
2. 總是在子類上實現接口更好嗎？

3. 你什么時候使用其中一個？

    public interface IFriendly { string GetFriendly(); } public abstract class Person: IFriendly { public abstract string GetFriendly(); } 

   VS.

    public interface IFriendly { string GetFriendly(); } public abstract class Person { // some other stuff i would like subclasses to have } public abstract class Employee : Person, IFriendly { public string GetFriendly() { return "friendly"; } } 

Answer 1

好吧，你需要這樣想：

public interface IBreathing
{
    void Breathe();
}

//because every human breathe
public abstract class Human : IBreathing
{
    abstract void Breathe();
}

public interface IVillain
{
    void FightHumanity();
}

public interface IHero
{
    void SaveHumanity();
}

//not every human is a villain
public class HumanVillain : Human, IVillain
{
    void Breathe() {}
    void FightHumanity() {}
}

//but not every is a hero either
public class HumanHero : Human, IHero
{
    void Breathe() {}
    void SaveHumanity() {}
}

關鍵是你的基類應該實現接口（或繼承，但只將它的定義暴露為抽象），只有從它派生的每個其他類也應該實現該接口。 因此，通過上面提供的基本示例，只有當每個Human呼吸時（這在這里是正確的），你才能使Human實施IBreathing 。

但！ 你不能讓Human實現這兩個IVillain和IHero ，因為這將讓我們無法辨別以后，如果它是一個或另一個。 實際上，這樣的實施意味着每個Human都同時成為惡棍和英雄。

要結束你的問題的答案：

1. 基類實現接口的缺點/風險是什么？

   沒有，如果從它派生的每個類也應該實現該接口。

2. 總是在子類上實現接口更好嗎？

   如果從基礎派生的每個類都應該實現該接口，那么它是必須的

3. 你什么時候使用其中一個？

   如果從基類派生的每個類都應該實現這樣的接口，那么make base class繼承它。 如果沒有，請使具體類實現這樣的接口。

Answer 2

從基類開始將您與基類的實現聯系起來。 我們總是開始認為基類正是我們想要的。 然后我們需要一個新的繼承類，它不太適合，所以我們發現自己回過頭來修改基類以適應繼承類的需要。 它一直在發生。

如果您從界面開始，那么您會有更多的靈活性。 您可以編寫一個實現該接口的新類，而不必修改基類。 你可以在它工作時獲得類繼承的好處，但是當它不起作用時你就不會依賴它。

我第一次使用OOP時，我喜歡類繼承。 令人驚訝的是它很少會變得實用。 這就是Composition Over Inheritance的主體所在的地方。最好是用類的組合來構建功能，而不是讓它嵌套在繼承的類中。

還有開放/封閉原則。 如果你可以繼承，那很好，但你不想返回並改變基類（並冒險破壞其他東西），因為新的繼承類需要正常工作。 對接口而不是基類進行編程可以保護您不必修改現有的基類。