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 simple : did you actually ever use it or worked on a successfully designed project using protected internal access modifier? If yes, please share your knowledge and post nice sample, where I can finally appreciate clever usage of this tricky modifier.

// I believe this isn't subjective, I am actually seeking for an answer ;-)

Answer 1

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 2

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