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

我今天正在做一些代码审查，遇到了一些开发人员编写的旧代码。它是这样的内部抽象方法。为什么会有人拥有它们？

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()

这让我想到了。为什么有人将一种方法声明为内部抽象？

来源

2010-02-20 ram

原始程序员想要将派生控件提供给客户端代码。但是要防止客户继承和混淆虚拟方法。这并不是一个坏主意，通过重写一个方法并执行一些类似于忘记调用基类方法的方法来打破基类通常很容易。

来源

2010-02-20 21:21:25

直到你第四次在第三方库中遇到这种居高临下的假设时，这可能不是一个坏主意。它通常意味着大量不必要的重复。（DevExpress，我看着你......） – jnm2 2014-07-16 17:29:05

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

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

来源

2010-02-20 20:35:32

否 - 如果要防止外部继承，则使构造函数成为内部函数。你不需要让整个班级都是内部的。 – RobSiklos 2013-06-07 18:02:29

使内部类和内部构造函数有什么区别？ – RSB 2015-01-16 13:25:58

@RobSiklos在什么情况下，应该让课程内部生成 – RSB 2015-01-19 05:33:35

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

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

来源

2010-02-20 20:36:34 itowlson

通过将方法定义为内部抽象，您希望确保只有同一个程序集中的类可以为您的方法实施它。

现在，如果你发布了一个dll，这将避免客户端继承和实现实现。

来源

2010-02-22 12:24:30

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

回答

相关问题