你见过合理使用protectedinternal访问修饰符的设计吗？我没有，但我不是说不。所有阅读本文的C#开发人员可能都知道什么是innerprotected以及何时使用它。我的问题很简单：您是否实际使用过它，或者在设计成功的项目中使用过protectedinternal访问修饰符？如果是，请分享您的知识并发布好的示例，我终于可以欣赏到这个棘手的修改器的巧妙使用。//我确定这不是主观的，我实际上是在寻找答案;-)我相信您可以想到示例，但是在C#开发的五年中，我还没有看到一个很好的示例它。JohnK的例子很好地说明了修饰符的预期用途，但我认为导致这种情况的要求是有问题的。在JohnK的示例中，该类在程序集中具有“友好”访问权限，这通常很麻烦，因为这些类可能是“询问”而不是“告诉”（糟糕的编程，告诉比询问更好）。在什么情况下你有一个有用的可扩展类，朋友可以调用方法而其他人不能？另一个用途是测试访问（IE希望它受到保护，但在内部以便您的程序集级别测试可以调用它）。这也是一个麻烦的情况——当你在内部公开东西进行测试时，我认为这是一种依赖注入通常可以处理的设计味道。是的，在继承的情况下，只要允许同一程序集（内部）中的其他类以“友好”/受信任的方式直接访问虚拟或抽象类成员，但该成员可以被派生覆盖组件外部的类（受保护）。这个组合修饰符允许一个程序集完全信任它自己的内容和内部使用（这也不例外），同时将它的一些成员暴露给其他程序集的正常继承派生模型。没有一个修饰符可以做到这一点。或者考虑相反的情况：Assembly1.dll//------Assemblyfile1.dll------//允许我的朋友（内部）和派生类（受保护）执行此操作。publicclassA{internalprotectedvirtualvoidYoBusiness(){//dosomething}}classB{//不是派生类-只是复合了ApublicB(){Aa=newA();;//感谢朋友访问！}}Assembly2.dll//------Assemblyfile2.dll----------classC:A{//跨程序集派生protectedoverridevoidYoBusiness(){//嘿，谢谢其他人，我可以提供一个新的实现。所有受保护或内部成员都会增加复杂性、耦合性，从而降低抽象完整性。您可能会考虑实施一些内部或受保护的方法，但通常使用内部或受保护的字段是一个非常糟糕的主意。受保护/内部字段将您的抽象实现“开放”给各种类，并使未来的修改变得非常复杂。我不喜欢像“从不”或“不要”这样的词作为设计指南，但我们绝对应该至少使用“避免”的建议作为一般设计指南。你真的用过吗？是的，使用InternalsVisibleTo进行单元测试。它仅适用于想要继承您的类型的人，因为他们与您不在同一家公司工作。但是，说真的，这个问题只适用于内部……我们知道你为什么要使用受保护的，对吧？那么，为什么是内部？可能仅当您知道您的类型访问某些仅在同一程序集中可用的资源时。无论是实际资源，还是您不想与世界共享的其他类型。事实上，今天是我职业生涯中第一次使用它！我有一个带有基类的插件架构，插件只通过外观类公开。限制插件使其只能通过faqade调用的唯一方法是使其在内部受到保护，因为覆盖它的插件位于不同的程序集中，而faqade层与基类相同我有点担心选择器会回来咬我，但不管怎样，我很乐意将事情公开以上是C#学习教程：你见过正确使用受保护的内部访问修饰符的设计吗？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
