我没有，但我不是说没有。
阅读本文的所有 C# 开发人员可能都知道什么是内部保护的以及何时使用它。我的问题很简单：您是否真的使用过它或使用受保护的内部访问修饰符成功设计过项目？如果是，请分享您的知识并发布漂亮的示例，我终于可以欣赏到这个棘手的修饰符的巧妙用法。
// 我相信这不是主观的，我实际上是在寻找答案;-)
【问题讨论】：
标签： c# access-modifiers
我相信你能想到例子，但是在五年的 C# 开发中，我还没有看到一个好的案例。 John K 的示例很好地说明了修饰符的预期用途，但是我认为导致这种情况的要求是有问题的。在 John K 的示例中，该类在程序集中具有“友好”访问权限，通常这很麻烦，因为这些类可能是“询问”，而不是“告诉”（编程不礼貌，最好告诉而不是询问）。在什么情况下，您有一个有用的可扩展类，Friends 可以调用方法，但其他人不能？
另一个用途是测试访问（您希望它受到保护，但在内部，因此您的组装级测试可以调用它）。这也是一个麻烦的情况 - 当您将事物公开为内部测试时，我认为这是依赖注入通常可以处理的设计气味。
【讨论】：
internal通过InternalsVisibleToAttribute 暴露给另一个程序集bit.ly/9UkCZe
是的，在继承情况下，只要允许同一程序集（内部）中的其他类以“友好”/受信任的方式直接访问虚拟或抽象类成员，但该成员也可以被派生覆盖外部程序集中的类（通过受保护）。
此组合修饰符允许程序集完全信任自己的内容和内部使用（这不是异常），同时将其中一些成员暴露给其他程序集的正常继承派生模型。
没有一个修饰符可以做到这一点。
或者考虑相反的情况：
如果您仅使用protected，则同一程序集中的其他类无法访问该成员。
如果您仅使用内部，则派生类（在其他程序集中）无法覆盖该方法。
Assembly1.dll
// ------ Assembly file 1 .dll --------
// Allow my friends (internal) and derived classes (protected) to do this.
public class A {
internal protected virtual void YoBusiness() {
//do something
}
}
class B { // not a derived class - just composites an instance of A
public B() {
A a = new A();
a.YoBusiness(); // Thanks friend for the access!
}
}
Assembly2.dll
// ------ Assembly file 2 .dll --------
class C : A { // derived across assemblies
protected override void YoBusiness() {
// Hey thanks other guy, I can provide a new implementation.
}
}
【讨论】：
protected internal 是什么，但没有描述它的实际用途。
所有protected 或internal 成员都会增加复杂性、耦合性并因此降低抽象完整性。您可能会考虑实现一些内部或受保护的方法，但通常使用内部或受保护的字段是非常糟糕的主意。受保护/内部字段“打开”您的抽象实现，适用于广泛的类和高度复杂的未来修改。
我不喜欢“从不”或“不”这样的词作为设计指南，但我们绝对应该至少使用“avoid" 建议作为通用设计指南。
【讨论】：
你真的用过吗
是的，以及用于单元测试的 InternalsVisibleTo。
【讨论】：
这只是对那些想继承你的类型的人刻薄，因为他们和你不在同一家公司工作。 ;-)
不过，说真的，这个问题仅适用于内部......我们知道您为什么要使用受保护的，对吧？那么，为什么是内部？可能只有当您知道您的类型访问某些仅在同一程序集中可用的资源时。无论是实际资源，还是您不想与世界分享的其他类型。
【讨论】：
实际上，我今天必须在我的职业生涯中第一次使用它！我有一个带有基类的插件架构，插件仅通过外观类公开。限制插件只能通过 faqade 调用的唯一方法是使其受内部保护，因为覆盖它的插件位于其他程序集中，而 faqade 层与基类位于相同
我有点担心选择会回来以某种方式咬我，所以我很想把事情公开
【讨论】：