Question

我有一个特殊的边缘情况，我不确定是使用接口还是抽象类。最初我的设计使用了一个抽象类，其中方法实现为protected internal abstract void。

这很有用，因为我希望这些方法可以在我的程序集中调用，但只能通过程序集之外的继承来实现。

我遇到的问题是并不是抽象类的所有派生都需要实现这个功能，所以基本上我最终得到了空方法体。

这就是我使用接口的想法，这意味着我可以通过接口实现所需的功能，但是这意味着这些方法需要是公共的，并且如上所述，我只希望方法是通过继承获得。

使用抽象类的示例：

abstract class Dependency
{
    protected internal abstract void DoThis();
    protected internal abstract void DoThat();
}

sealed class DerivedDependency : Dependency
{
    protected override void DoThis()
    {
        // implementation...
    }

    protected override void DoThat()
    {
        // not required...
    }
}

使用接口的示例：

abstract class Dependency
{
    // whilst this is now empty, it is still required to provide a type hierarchy!
}

interface IDoThis
{
    void DoThis();
}

interface IDoThat
{
    void DoThat();
}

sealed class DerivedDependency : Dependency, IDoThis
{
    public virtual void DoThis()
    {
        // I only need this functionality. I don't need to DoThat();
    }
}

所以我想知道什么是更好的。两者都提供我想要的功能，但似乎我不能同时拥有这两种功能。

我是否只是忍受第三方可能实现的空方法体，没有意识到它们并不意味着实现，或者，我是否只实现所需的功能，但是有可能通过实例化暴露功能？ / p>

Answer 1

提到实体，你缺少的是接口隔离原则，你应该使用两个接口，一个用于内部消费者（标记为内部的方法），另一个用于外部消费者。

所以我不会使用抽象类，也不会使用接口，而是使用两个（或更多）接口。

Answer 2

我可能已经找到了一个似乎运行良好的解决方案，但我希望社群就这是否遵守或违反SOLID原则提出意见：

interface IDoThis
{
    void DoThis();
}

class Dependency : IDoThis
{
    protected internal virtual void DoThis()
    {
        // impl.
    }

    void IDoThis.DoThis()
    {
        this.DoThis();
    }
}

IDoThis idt = new Dependency();
idt.DoThis() // calls into the protected method.

这允许我通过接口（ISP）隔离功能，在程序集中公开访问它，并在外部程序集（OCP）中覆盖它

SOLID原则：接口与抽象类

2 个答案: