当某些方法不会被使用/不实现时，使用接口还是抽象类？

发布于 2024-10-16 19:57:20 字数 227 浏览 4 评论 0原文

我有一个项目，其中将抽象地定义相当多的函数和变量获取器。我的问题是我应该为此使用一个抽象类（每个函数都会抛出 NotImplementedException），还是应该使用一个接口？或者我应该同时使用两者，创建一个接口，然后创建一个实现该接口的抽象类？

请注意，即使可以定义所有这些函数等，但这并不意味着它们将在所有用例中使用。例如，身份验证类中的 AddUser 可能在接口中定义，但由于封闭的用户注册而从未在网站中使用。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

递刀给你 2024-10-23 19:57:20

一般来说，要不要使用继承或接口的问题的答案可以这样思考：

当考虑假设时
实现类，是这样的吗
这些类型就是我的类型
描述，或者是这样的情况
这些类型可以或可以做我正在做的事情
描述？

例如，考虑 IEnumerable 接口。实现 IEnumerable 的类都是不同的类。它们可以是一个可枚举的结构，但它们本质上是其他东西（List或Dictionary或查询等）

另一方面，查看 System.IO.Stream 类。虽然从该抽象类继承的类不同（例如，FileStream 与 NetworkStream），但它们本质上都是流，只是类型不同。流功能是定义这些类型的核心，而不是仅仅描述类型的一部分或它们提供的一组行为。

通常你会发现两者都做是有益的；定义一个定义您的行为的接口，然后定义一个实现它并提供核心功能的抽象类。如果合适的话，这将使您能够两全其美：当功能是核心时可以继承一个抽象类，当功能不是核心时可以实现一个接口。

另外，请记住，仍然可以通过使用扩展方法在接口上提供一些核心功能。严格来说，虽然这并没有将任何实际的实例代码放在界面上（因为这是不可能的），但您可以模仿它。这就是 LINQ-to-Objects 查询函数通过静态 Enumerable 类在 IEnumerable 上工作的方式，该类定义用于查询泛型 的扩展方法>IEnumerable 实例。

附带说明一下，您不需要抛出任何 NotImplementedException。如果您将函数或属性定义为抽象，那么您不需要（实际上也不能）在抽象类中为其提供函数体；继承类将被迫提供方法体。它们可能会抛出这样的异常，但这不是您需要担心的事情（对于接口也是如此）。

In general, the answer to the question of whether or not to use inheritance or an interface can be answered by thinking about it this way:

When thinking about hypothetical
implementing classes, is it a case
where these types are what I'm
describing, or is it a case where
these types can be or can do what I'm
describing?

Consider, for example, the IEnumerable<T> interface. The classes that implement IEnumerable<T> are all different classes. They can be an enumerable structure, but they're fundamentally something else (a List<T> or a Dictionary<TKey, TValue> or a query, etc.)

On the other hand, look at the System.IO.Stream class. While the classes that inherit from that abstract class are different (FileStream vs. NetworkStream, for example), they are both fundamentally streams--just different kinds. The stream functionality is at the core of what defines these types, versus just describing a portion of the type or a set of behaviors that they provide.

Often you'll find it beneficial to do both; define an interface that defines your behavior, then an abstract class that implements it and provides core functionality. This will allow you to, if appropriate, have the best of both worlds: an abstract class for inheriting from when the functionality is core, and an interface to implement when it isn't.

Also, bear in mind that it's still possible to provide some core functionality on an interface through the use of extension methods. While this doesn't, strictly speaking, put any actual instance code on the interface (since that's impossible), you can mimic it. This is how the LINQ-to-Objects query functions work on IEnumerable<T>, by way of the static Enumerable class that defines the extension methods used for querying generic IEnumerable<T> instances.

As a side note, you don't need to throw any NotImplementedExceptions. If you define a function or property as abstract, then you don't need to (and, in fact, cannot) provide a function body for it within the abstract class; the inheriting classes will be forced to provide a method body. They might throw such an exception, but that's not something you need to worry about (and is true of interfaces as well).

回复收藏 0 原文

哭泣的笑容 2024-10-23 19:57:20

就我个人而言，我认为这取决于“类型”的定义。

如果您要定义一组行为，我会推荐一个接口。

另一方面，如果类型确实定义了“类型”，那么我更喜欢抽象类。不过，我建议让方法保持抽象，而不是提供空的行为。

请注意，尽管可以定义所有这些函数等，但这并不意味着它们都会在所有用例中使用。

如果这是真的，您应该考虑将其分解为多个抽象类或接口。在基类/接口中使用“不适当”的方法确实违反了里氏替换原则，以及设计缺陷的迹象。

回复收藏 0 原文

变身佩奇 2024-10-23 19:57:20

如果您不提供任何实现，则使用接口，否则使用抽象类。如果有一些方法可能无法在子类中实现，那么创建一个中间抽象类来完成抛出 NotSupportedException 或类似的工作可能是有意义的。

回复收藏 0 原文

っ〆星空下的拥抱 2024-10-23 19:57:20

抽象类的优点之一是，可以向抽象类添加新的类成员，其默认实现可以用现有的类成员来表示，而不会破坏该类的现有继承者。相比之下，如果向接口添加任何新成员，则必须修改该接口的每个实现以添加必要的功能。

如果 .net 允许接口包含不使用任何对象字段的属性、方法和事件的默认实现，那就太好了。从技术角度来看，我认为通过为每个接口提供一个默认 vtable 条目列表（可以与不定义所有 vtable 插槽的实现一起使用），可以毫不费力地完成这样的事情。不幸的是，.net 中不存在这样的能力。

回复收藏 0 原文

救星 2024-10-23 19:57:20

当您可以提供部分实现时，应该使用抽象类。当您根本不想提供任何实现（仅提供定义）时，请使用接口。

在你的问题中，听起来好像没有实现，所以使用接口。

另外，您应该使用 abstract 关键字声明您的方法/属性，而不是抛出 NotImplementedException ，以便所有继承者都必须提供实现。

回复收藏 0 原文

话少情深 2024-10-23 19:57:20

@Earlz我认为参考这个：注意，即使所有这些函数等都可能被定义，但这并不意味着它们都会在所有用例中使用。与最佳方法直接相关来‘攻击’这个问题。

您应该瞄准的是最大限度地减少此类函数的数量，以便在您使用或时它变得无关紧要（或至少不那么重要）。因此，尽可能地改进设计，您会发现走哪条路并不重要。

更好的是发布你正在尝试做的事情的高水平，让我们看看我们是否可以想出一些好的东西。更多的大脑朝着共同的目标努力将会得到更好的答案/设计。

回复收藏 0 原文

此生挚爱伱 2024-10-23 19:57:20

在某些情况下有效的另一种模式是创建一个非抽象的基类。它有一组定义 API 的公共方法。其中每一个都调用一个 Overideable 的受保护方法。
这允许派生类选择它需要实现的方法。
例如

 public void AddUser(object user)
    {
        AddUserCore(user);
    }

    protected virtual void AddUserCore(object user)
    {
        //no implementation in base
    }

Another pattern that works in some situations is to create a base class that is not abstract. Its has a set of public methods that define the API. Each of these calls a Protected method that is Overideable.
This allows the derived class to pick and choose what methods it needs to implement.
So for instance

 public void AddUser(object user)
    {
        AddUserCore(user);
    }

    protected virtual void AddUserCore(object user)
    {
        //no implementation in base
    }

回复收藏 0 原文

~没有更多了~