Access Modifiers Convention Definition:

Helps to comply with one of the three pillars of Object Oriented Programming: Encapsulation. By setting standards for the use of Private, Public, Internal, Protected and Protected Internal Access Modifiers by C# Types

Access Modifiers Convention Justification:

Encapsulation, or Data Hiding, is one of the primary Pillars of Object Oriented Programming. The Data Hiding principle states that consuming software entities should not have knowledge of the internal workings of an Entity. The only information that should be exposed is the results of an Entity that are presented for consumption.

Access Modifiers Conventions Standards:

C# has five access modifiers to manage OOP encapsulation. These modifiers manage access at these levels:

1. Type Level Restriction

2. Type Inheritance Level Restriction

3. Assembly Level Restriction

4. No Restriction

The Five C# Access Modifiers:

1. Private – No assess outside of the defining Entity Type

2. Protected – Access to the defining Type and all derived Types

3. Internal – Access to all Entity Types within an Assembly

4. Protected Internal – Access limited to the Assembly or Types derived from a containing Class

5. Public – No Restrictions of any kind

Below are the default modifiers for the major C# types:

1. Namespace – No modifiers allowed. Namespaces are always public

2. Class – internal with Member Default of private: Allowed Modifiers – public, internal, protected, protected internal, private

3. Interface – public: Allowed Modifiers – None

4. Enum – public: Allowed Modifiers – None

5. Struct – public with Member Default of private: Allowed Modifiers – None

The development standard should be a “Most Restrictive” philosophy. Use Data Hiding to restrict to the highest degree and allow looser access only when required.

Sometimes classes, such as Testing Assemblies, needs access to members that you may not want to expose to the outside world. C# gives us the ability to access members with the internal access modifier even if we are not part of the dependency assembly through the use of a “Friendly Assembly” assembly declaration.

This access is granted by the dependency assembly. It gives a designated assembly .ddl access to all members that have an internal access modifier. This is how you can test what will become private methods by temporally assigning an access modifier of internal.

You create a “Friendly Assembly” with an “InternalsVisibleTo” assembly attribute inside of an Assembly’s Properties folder’s AssemblyInfo.cs file:

[assembly: InternalsVisibleTo(“Widgets.CustomerContacts.Tests”)]

You will want to return the access to private once the validation is completed, if possible.

In Unit Testing we test the behavior of a Type not the internal workings of private Helper methods. Sometimes, during Test first development, we need to validate that a private helper is functioning but we do not need to maintain that unit test for the life cycle of the assembly. We can use InternalsVisibleTo” assembly attribute to gain us access for internal validation and then return the member to its correct private access limitation.