In C# 7.2, Microsoft introduced the `private protected` access modifier to further refine the accessibility of class members. It presents developers with more control over member access within an inheritance hierarchy, allowing for scenarios that previously required less preferred workarounds or redesigns.

Understanding Access Modifiers

Before diving into the `private protected` modifier, it's crucial to briefly recap the existing access modifiers in C#:

• `public`: Any code can access public members.
• `private`: Only the containing class can access private members.
• `protected`: Access is limited to the containing class and any derived classes.
• `internal`: Access is limited to the current assembly.
• `protected internal`: A logical OR of `protected` and `internal`.

These modifiers grant flexibility but don't particularly help when there's a need to limit access to derived classes within the same assembly — a feature sometimes useful in large-scale applications.

Introduction to `private protected`

The `private protected` access modifier is a hybrid that offers nuanced control. Specifically, it restricts member access to the containing class or types derived from the containing class, but only within the same assembly.

This modifier can be thought of as an AND combination of `protected` and `internal` — access is confined to child types within the same assembly.

Technical Explanation

Consider `private protected` as a subset of the `protected internal` modifier:

• If `protected internal` allows access if either `protected` or `internal` conditions are met,
• Then `private protected` only grants access when both conditions (`private` and `protected`) are satisfied.

Example

• Internal Framework Development: Useful in larger projects where a module or library is developed and needs to expose certain inheritance APIs only within that module.
• Encapsulation with Hierarchy: Ensures encapsulation by allowing access to crucial base functionality or state only within a trusted subset of types, preventing unintended access by external consumers.
• Restricting API Surface: Works best when you need an API that's protected in nature but doesn't span across assembly boundaries, offering a tighter access control.
• Version Control & Refactoring: By restricting member accessibility, `private protected` ensures that changes remain predictable and contained, reducing the risk when refactoring.
• Unit Testing: Designed as part of internal APIs, you can better control access paths, easing the creation of unit tests that focus on inherited functionality within a module.