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

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 2

did you actually ever use it

Yes, along with InternalsVisibleTo for unit testing.

Answer 3

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 4

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.