Have you ever seen design with reasonable usage of protected internal access modifier?

Question

I haven\'t, but I don\'t say there isn\'t one.

All of the C# developers who read this probably do know what is protected internal and when to use it. My question is simp

Answer 1

All protected or internal members increase complexity, coupling and therefore reducing abstractions integrity. You may thinking implementing some methods internal or protected, but using internal or protected fields in general is very bad idea. Protected/internal fields "open" your abstractions implementation for wide range of classes and highly complicate future modifications.

I don't like words like "never" or "do not" as design guidelines, but we definitely should use at least "avoid" suggestion as common design guideline.

Answer 2

I'm sure you can think of examples, but in five years of C# development, I've not seen a good case for it. John K's example illustrates the intended use of the modifier nicely, however I think the requirements that lead to this situation are problematic. In John K's example, the class has "friendly" access within the assembly, and in general this is trouble, because those classes are probably "asking", not "telling" (programming is not polite, it is better to tell than to ask). In what case do you have a useful extendable class that Friends can call a method on but others cannot?

Another use would be for testing access (IE you want it to be protected, but internal so your assembly level tests can call it). This is a trouble situation too - when you expose things as internal for testing I think it is a design smell that dependency injection can usually handle.

Answer 3

It's just to be mean to people who want to inherit from your type, because they don't work for the same company as you. ;-)

Seriously, though, the question applies to internal alone ... we know why you'd use protected, right? So, why internal? Probably only when you know that your type accesses some resources that are only available within the same assembly. Whether that is an actual resource, or another type that you don't want to share with the world.

Answer 4

did you actually ever use it

Yes, along with InternalsVisibleTo for unit testing.

Answer 5

Yes, in an inheritance situation whenever a virtual or abstract class member was allowed to be directly accessed by other classes inside the same assembly (internal) in a "friendly"/trusted manner, but also that member could be overriden by derived classes in external assemblies (via protected).

This combo modifier allows the assembly to fully trust its own contents and internal usage (which is not abnormal), while exposing some of those members to the normal inheritance derivation model for other assemblies.

No single modifier can do this.

Or consider the reverse situations:

• if you only use protected then other classes inside the same assembly cannot access that member.

• if you only use internal then derived classes (in other assemblies) cannot override that method.

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. 
    }
}

Answer 6

I actually had to use it for the first time in my career today! I have an plugin architecture with baseclases and the plugins are exposed only through a facade class. The only way to restrict so that the plugin is callable only through the faqade is to make it protected internal since the plugins that override it lies in other assemblies while the faqade layer lies in the same as the base class

I'm a bit worried that the choice will come back to bite me somehow though so I'm tempted to just make things public