Helper Classes

On our blog we spent few words about the architecture of a component in Flex / Air applications https://gnstudio.wordpress.com/2009/10/11/de-architectura-mvp-in-flex-air-components/ identifying which are the building blocks of well organized component.
It’s the time to clarify the nature of the classes that we imagine to find in the helpers packaging.
Traditionally an helper class is a class made up by static methods used to isolate useful algorithms, the way we expect helper classes in a Flex / Air application is a little bit different because we really believe that a class filled with static methods is an example of laziness and a way to break down any pattern.
We are not saying here that helper classes are not useful, our willing is to enforce their usage avoiding common mistakes.

The first mistake that we usually see in an helper class filled with static methods is the violation of the Single Responsibility principle. This principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class, during the development, especially with time constraints, the main temptation is to use static classes to group together algorithms that do similar things but that probably mix together different responsibilities.
Make an helper class not static help us to think if it’s correct to add a method to this class or if a new helper class is needed.
Moreover a class with static method make very difficult the identification of problems if you do test driven development, so we strongly encourage to avoid them.
An helper class written without static methods can be easily instantiated, used and destroyed from any component so it takes part to the overall application architecture and it doesn’t act as a garbage disposal for methods that a developer doesn’t know where to put in the application packaging.
We encourage all the team to consider also that an helper class should keep safe also the Open Closed Principle (software entities should be open for extension, but closed for modification) and for this reason an helper class that is not filled by static methods can be easily extended in order to avoid code smells like duplication and cross packaging references.
Our feeling is that a well designed helper class (good design starts from small classes) can be useful and productive in an enterprise application and we encourage to use them with the SOLID principles in mind

SRP     The Single Responsibility Principle
OCP     The Open Closed Principle
LSP     The Liskov Substitution Principle
ISP     The Interface Segregation Principle
DIP     The Dependency Inversion Principle

And writing them in the right package in order to keep the packaging flexible or even better maintainable.

This entry was posted in Best Practices, RIA. Bookmark the permalink.

One Response to Helper Classes

  1. Pingback: 2010 in review « Gnstudio’s Weblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s