内部抽象方法。为啥会有人拥有它们？

Posted 2023-02-25

【中文标题】内部抽象方法。为啥会有人拥有它们？

【英文标题】：internal abstract methods. Why would anyone have them?内部抽象方法。为什么会有人拥有它们？

【发布时间】：2011-01-19 04:52:02

【问题描述】：

我今天在做一些代码审查，偶然发现了一些开发人员编写的旧代码。它是这样的

public abstract class BaseControl

    internal abstract void DoSomething();

如果你在同一个程序集中有一个派生类，它会起作用

public class DerivedControl : BaseControl

    internal override void DoSomething()
    
    

但是在不同的程序集中派生基类会产生编译时错误

DerivedControl does not implement inherited abstract member 'BaseControl.DoSomething()

这让我开始思考。为什么会有人将方法声明为内部抽象？

【参考方案1】：

我最初的反应是没有充分的理由，如果你想阻止外部继承，那么你应该将类标记为内部。但这意味着该类对其他程序集完全隐藏。

我想这种方法可以在保持可见性的同时防止外部继承。

【讨论】：

否 - 如果您想防止外部继承，您可以将构造函数设为内部。您无需将整个类设为内部。

类内部化和构造函数内部化有什么区别？

@RobSiklos 在什么情况下，应该将类设为内部

@RSB 如果您不想在公共 API 中公开该类，请将其设为内部。

【参考方案2】：

一个明显的情况是方法接收或返回内部类型。例如，WPF 转换类的核心方法处理一些内部互操作类型，WPF 不会将其作为其公共 API 的一部分公开。因为签名包括内部类型，所以该方法不能是公共的或受保护的。然而很明显，各种 Transform 类以多态方式工作是合适的（必要的！）。因此，Transform/GeneralTransform 中的基本方法必须是内部的。

另一个但相关的原因是防止外部派生。毕竟，WPF 架构师可以在受保护的抽象方法中公开内部互操作类型的“安全”版本，以便用户可以创建自己的 Transform 类。他们没有这样做是因为他们不想应付人们可能使用这种能力的方式，例如。创建非仿射变换。允许外部派生会使 WPF 中其他类的工作变得非常复杂，因此架构师决定通过将抽象方法设为内部来仅允许“批准”的派生类。

【参考方案3】：

最初的程序员希望为客户端代码提供派生控件。但是要防止客户端继承和弄乱虚方法。这不是一个坏主意，通过重写方法并执行诸如忘记调用基类方法之类的操作通常很容易破坏基类。

【讨论】：

在您第四次在第三方库中遇到这种居高临下的假设之前，这可能不是一个坏主意。这通常意味着大量不必要的重复。 （DevExpress，我在看着你……）

【参考方案4】：

通过将方法定义为内部抽象，您希望确保只有同一程序集中的类才能实现您的方法。

现在，如果您分发它的 dll，这将避免客户端继承和中断实现。