内部抽象方法。为什么会有人拥有它们？我今天正在做一些代码审查，发现了一些开发人员编写的旧代码。就像这个publicabstractclassBaseControl{internalabstractvoidDoSomething();如果你在同一个程序集中有一个派生类publicclassDerivedControl:BaseControl{internaloverridevoidDoSomething(){}}它会起作用但是在不同程序集中派生基类会产生编译时错误DerivedControldoesnotimplementinheritedabstractmember'BaseControl.DoSomething()这让我开始思考。为什么有人会将方法声明为内部抽象？最初的程序员想要为客户端代码提供派生控件。但是为了防止客户端继承和弄乱虚拟方法。这不是一个坏主意，通常很容易通过重写一个方法并做一些像忘记调用基类方法这样的事情来破坏基类。一个明显的例子是接收或返回内部类型的方法。例如，WPF转换类的核心方法处理一些内部互操作性类型，WPF没有将这些类型作为其公共API的一部分公开。该方法不能是公共的或受保护的，因为签名包含内部类型。但很明显，各种Transform类以多态方式工作是合适的（必要的！）。因此，Transform/GeneralTransform中的基方法必须是内部的。另一个相关的原因是防止外部推导。毕竟，WPF架构师可以在受保护的抽象方法中公开内部可互操作类型的“安全”版本，以便用户可以创建自己的Transform类。他们不这样做是因为他们不想处理人们使用这种能力的方式，例如创建非仿射变换。允许外部派生会使WPF中其他类的工作变得非常复杂，因此架构师决定通过在内部创建抽象方法来仅允许“批准的”派生类。我最初的反应是，没有充分的理由，如果你想防止外部继承，那么你应该将类标记为内部类。但这意味着该类对其他程序集完全隐藏。我想这种方法可以在保持可见性的同时防止外部继承。通过将方法定义为内部抽象，您需要确保只有同一程序集中的类才能为您的方法实现它的实现。现在，如果您分发一个dll，这将避免客户端继承并消除实现。以上就是C#学习教程：内部抽象方法。为什么会有人拥有它们？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
