【发布时间】：2011-02-21 16:49:32
【问题描述】：
如果我有一个带有我想要protected 和internal 的方法的类。我希望只有程序集中的派生类才能调用它。
由于protected internal 表示protected 或 internal，您必须做出选择。在这种情况下你会选择什么 - protected 或 internal？
【问题讨论】：
标签： c# protected internal access-levels
【发布时间】：2011-02-21 16:49:32
【问题描述】：
我认为正确的选择是internal。通过这种方式，您可以保护程序集之外的人不调用此方法，这只会让您小心，并且只能从派生类中调用此方法。在你编写的程序集中小心，比希望其他人在使用它时小心更容易。
【讨论】：
我个人会选择受保护的。如果您自己程序集中的子类足以调用该方法，那么为什么另一个程序集中的子类不能呢？也许您可以将功能完全重构为一个单独的（内部）类。
您确实需要客观地考虑该方法的目的。内部可访问性对我来说几乎总是感觉不对。主要是因为我在尝试从 .NET 框架中的控件或类派生时遇到了困难，因为有人决定将 class 或 方法标记为内部方法。原作者从未注意到无法访问该方法会使实现子类变得更加困难。
编辑
为了澄清，一个类的内部可访问性非常有用，我并不是在暗示内部一般来说是不好的。我的观点是，在其他公共类上的内部方法对我来说似乎是错误的。设计合理的基类不应为同一程序集中的派生类提供不公平的优势。
【讨论】：
-
如果您对程序集类进行了反射，并且如果子类不会被反射（因为它在程序集之外），那么这种方法将无法正常工作？
-
简单问题。我也从来不用反射
:) -
@Kobi，你从不使用属性？
-
-1 你做错了。如果您正在编写 API，并且您正在创建仅适用于程序集内部的类（帮助程序/实用程序类），那么您肯定不希望用户从这些类派生。如果您允许他们，他们将编写代码，将依赖项添加到内部实现（如果不惹恼您的用户，将来就不可能更改）。一切，我重复所有你没有明确设计让你的用户访问的一切都应该标记为内部或私有。
-
(cont) 不这样做只会让用户有更多方式以非预期的方式入侵您的库，从而使其更难以支持。另外，为了有效地记录 API，所有标记为公开的内容（在理想情况下）都应该正确注释。 .NET 框架的某些部分不允许您访问是有充分理由的。
让protected internal 意味着protected 或internal 真是一个古怪的决定。对于这种精确的情况，我会使用internal。原因是如果封装被破坏，我宁愿是我，而不是不受我控制的人。
【讨论】：
我认为答案因您的需求而异。 如果我是你，我会这样做：
public class YourClass
{
protected class InnerClass
{
internal void YourMethod()
{
// Your Code
}
}
}
【讨论】：
我希望只有程序集中的派生类才能调用它。
那么，你有两个选择。你可以让它受到保护，每当你的一个客户扩展你的类并调用你的方法并且你发现它时，你可以给他们写一封措辞严厉的信，告诉他们请停止这样做。或者您可以将其设为内部，并对您同事的代码进行代码审查，以确保他们不使用他们不应该使用的方法。
我的猜测是后者是更便宜和更容易做的事情。我会把它变成内部的。
【讨论】：
-
可能还有第三种选择。 OP 可以使 整个类 内部化，在这种情况下，
protected访问该方法将实现期望的行为。程序集之外的代码可以通过公共接口访问类的功能。这可能足以实现 OP 的预期行为。当然，缺点是禁止在程序集之外进行所有继承......但 OP 并未明确指出这是一项要求。