C#接口类+继承VS纯抽象类答案

【问题标题】：C# Interface class + inheritance VS pure Abstract classC#接口类+继承VS纯抽象类
【发布时间】：2014-10-09 13:01:18
【问题描述】：

这种 OOP 方法注定要失败还是有什么好处？

在我理解抽象类之前，通过使用接口类 + 实现接口的某些方法的常规类，我或多或少地获得了代码重用的相同好处。例如

public interface IMyService
{
    String Helloword1();
    String Helloword2();
    String Helloword3();
}

public class MyService
{
    public String Helloword1(){return "1";}
    public String Helloword2(){return "2";}
    //Helloworld3 is not here so I would be forced to provide implementation in any subclass
    //very similar to calling abstract on a method
}



public class SubClass1: MyService, IMyService
{

    public String Helloword3(){return "3";}

}


public class SubClass2: MyService, IMyService
{

    public new String Helloword2(){return "override method";}
    public String Helloword3(){return "3";}

}

任何人都可以看到这样做有什么好处，或者这真的提供了与抽象类相同的好处吗？

【问题讨论】：

请注意SubClass2.Helloword2() 隐藏 MyService.Helloword2()，它不会覆盖它。

标签： c# oop interface polymorphism abstract

【解决方案1】：

任何人都可以看到这样做有什么好处，或者这真的提供了与抽象类相同的好处吗？

这样做有一个很大的缺点。你允许人们继承MyService而不实现Helloword3，因为这不是合同的一部分。

抽象类将强制该类型实现该成员。在这里，您相信用户会实现“必需”接口。

【讨论】：

当然，在 OP 的情况下，没有真正的理由禁止创建 MyService 类型。无法实际构造抽象类的原因不仅仅是没有真正增加价值的任意限制，而是限制的存在正是因为抽象类依赖于尚未实现的行为，这是它们的真正力量.在这里，OP 的类本质上不是抽象的，在概念意义上，因为没有真正的理由您不应该能够构造它的实例。

【解决方案2】：

在您的示例中，实际上有人可以构造MyService 的实例并在不使用抽象方法的情况下使用它。

老实说，在您的两个子类中甚至没有任何需要继承 MyService 的形式。如果可以具体创建MyService，则可以组合该类型，而不是继承自。

抽象类中的 real 值是具体方法实际使用抽象方法的地方。能够写出这样的东西：

public abstract class Foo
{
    public abstract Guid CreateUniqueIdentifier();
    public void SaveToDatabase()
    {
        Guid guid = CreateUniqueIdentifier();
        //do stuff with guid
    }
}

你不能用你的模式做这样的事情；具体方法永远不能依赖于尚未实现的方法。

【讨论】：