Helper Classes Guidelines
Helper Convention Definition:
The proper Use of Helpers Classes to Encapsulate Public Classes for Code Reuse capability
Helper Convention Justification:
Public Helper Classes are a critical part of one of the Pillars of Object Oriented Programming (OOP): Encapsulation.
By creating these Software Entity Types we are also complying with the “O” in S.O.L.I.D. Design Principles: The Open / Closed Principle. The Open / Closed principle states that a Software Entity should be Open for Extension but Closed for Modification.
Helper Classes abstract away the inner details of the desired functionality from the calling Type so that it can concentrate on its single responsibility contract with its calling Type.
There is a real performance benefit to complying with these practices for the Common Language Runtime (CLR).
The Just-In-Time (JIT) compiler, when compiling Intermediate Language (IL) code for use by the CLR can use some memory efficiency techniques while processing the calling Type’s Methods using these best practices.
Rather than assigning individual blocks of Managed Heap memory for all of the Method’s code block, which has to then be managed by the Garbage Collector as separate larger code memory, JIT can use registers in memory to create a single address pointer.
JIT can then access the pointer in the Stack memory for each abstracted method using only the method signature, not the entire implementation code.
This JIT Process is referred to as the Enregistering Process
If you have a Conditional block, such as nested “if” statements or a Switch Case statement, and 90% or better of the time one condition is met, CLR will never see the code for the unused methods.
The JIT will only serve Method Implementations that are Enregistered to CLR when they are called…
… If the code blocks are not Abstracted through Enregistering…
…… The CLR gets All code blocks that it May Never Use
If you think of all of the Conditional that an Enterprise Application supports I think you can easily understand the justification for allowing the JIT to implement the Enregistering technique.
Helper Convention Standards:
The Helper Class standards will aid to a better understanding of the intent of the underlying Software Entity.
By focusing the code implementation, within the Code Block on the Single Responsibility, and not the Details of how that Responsibility is being carried out for the calling Software Entity, Helper Methods support Open/Closed Principle.
The Coding Standards for Helper Methods:
Helper Classes. and the documentation of the common reuse types, needs to be organized in a fashion that supports ease of understanding of the contents of the Helper Class.
By organizing the contents of the Helper Class into common related functionality: A Single Responsibility.
Location and use of the shared functionality will be easily catalogued and easier to locate within the code assemblies when a functionality is required .
Code is deemed to be reusable if there is a “Two or More” relationship to its functionality.
All Helper Classes have an Access Modifier of public and should be available to all consuming types that have registered a dependency on that Common Assembly .
All helper Classes and the containing Helper Methods should be well documented for Development Team use.
Documentation Compliance should be Enforced during Code Review
This practice is critical as they serve minimum purpose if Developers are violating the “DRY Principle, Don’t Repeat Yourself”, by creating duplicate functionality.
The functionality of all Methods within the Class should have been validated upon creation using Test First Development (TDD) and moved to the Public Helper Class when properly vetted.
All Methods will be Static. A Static Constructor should be used to initialize any Class level Properties
A Nested Class has been deemed to only Support Value for the Parent Class
Helper Classes, by definition, support a “Two or More” relationship for consuming Types.
All Helper Methods that would be in that Private Helper Class will be encapsulated inside of a Helper Region and exposed as private methods for the Parent Class.
Helper Class Method Consideration as an Extension Method could Prevent what could be Perceived as Duplicate Functionality
This practice will have an additional development benefit by appearing in Intellisense for use by the Developer.
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016