Access Modifier Conventions
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:
Type Level Restriction
Type Inheritance Level Restriction
Assembly Level Restriction
The Five C# Access Modifiers:
Private – No assess outside of the defining Entity Type
Protected – Access to the defining Type and all derived Types
Internal – Access to all Entity Types within an Assembly
Protected Internal – Access limited to the Assembly or Types derived from a containing Class
Public – No Restrictions of any kind
Below are the default modifiers for the major C# types:
Namespace – No modifiers allowed. Namespaces are always public
Class – internal with Member Default of private: Allowed Modifiers – public, internal, protected, protected internal, private
Interface – public: Allowed Modifiers – None
Enum – public: Allowed Modifiers – None
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:
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.
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services