Question

这种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";}

}

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

Answer 1

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

这样做有一个很大的缺点。您允许人们在没有实施MyService的情况下继承Helloword3 ，因为这不是合同的一部分。

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

Answer 2

在你的例子中，有人可以实际构造一个MyService的实例，并在不使用抽象方法的情况下使用它。

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

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

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

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

C＃接口类+继承VS纯抽象类

2 个答案: