Rabeeh Abla

Software Architect @ GlobalVision

Help your helper classes By Defining their context & responsibility


Help your helper classes by defining their context & responsibility at class design time, and applying refactoring techniques.

Each class should state clearly what are its responsibilities and roles in the context it is located in.

Appending the keyword helper to classes is getting misused and becoming a bad habit. Imagine having code with 30 or more helper classes, first people would start thanking language designer that they made use of namespaces, still this does not remove the ambiguity from helper classes and the duplication of code that is occurring in them.

The idea of a class to be helper to another class bounds its responsibility to helping a specified class or set of specified classes, and this causes less use of helper class in libraries or small frameworks, because most of the time there is no specified role for the helper class except helping and this is an ambiguous role because it could be anything!

This problem can be solved by defining unambiguous responsibilities and roles to the class, and naming the class with a name that reflects its responsibilities and roles, in addition that the class exposed functions and methods should satisfy the class responsibilities and roles. I recommend applying refactoring techniques available on http://www.refactoring.com/catalog/index.html, the following refactoring techniques are the most beneficial for such scenario "Extract Superclass", "Extract Class", "Extract Subclass", "Move Class".


All classes communicate & help each other under specified roles and responsibilities, these factors are the constraints that make system responsibilities and roles clear and maintainable. Misusing the helper concept causes the formation of an ambiguous system.  

Take the following very basic and simple example:

We have a class called ‘Help’ that is responsible for viewing a special help file, and we have another class that helps the ‘Help’ class, I am going to name it as some programmers are doing these days, we will call the class ‘HelpHelper’ it saves and reads special help files. This is an example of bad naming that does not reflect the class responsibilities and roles. 

While we can name the preceding classes as the following and specify unambiguous responsibilities and roles:
 

The ‘Help’ can be named ‘HelpViewer’ that has the responsibility and role of viewing a special help file, and the ‘HelpHelper’ helper class to ‘HelpFileManager’ that is responsible for managing the saving and reading, this a clear specification, that allows better maintainability and clear extension of classes in a framework or library. 

 


My advice is to decrease the use of naming classes as helpers and work on specifying unambiguous responsibilities and roles for classes, to allow people working in this domain to have better understanding of the classes they are dealing with, for maintenance, testing, extendibility, effective use reasons.

Is there a class named with the Helper keyword in .net Framework? And if there exists, what is the number? 

Sincerely
Rabeeh Abla

 

Posted: Dec 07 2008, 10:10 PM by rabeehabla | with 4 comment(s) |

Comments

Joseph Ghassan said:

Naming classes with the help keyword is surely a bad practice.

If a class offer some sort of a service to other class and that is too generic to give it a name, just make this class part of the main class.

Helper methods do exists though, and I saw many source codes for known developers using it in their daily design.

If a method is too generic to give it a name and does something to 'help' other method to do its job, qualifying it as a 'helper method' would be appropriate.

It is really rare to define the context of a method or a class because at the end of the day, if you want to write functional code, each function should define what it will acheive in the system, otherwise we will have 'spaghetti' code everywhere.

If you ever feel the need to name some methods helpers for a main method just create a new region in your code as follows :

private void ReadFile(string path)

{

  //do something ( call helper methods )

}

#region ReadFile helper methods

     //Helper methods implementation    

#endregion

I think this will help structuring the code and make it more usable for anyone that want to inspect it.

Just my 2 cents...

# December 8, 2008 3:10 AM

Joseph Ghassan said:

Some corrections.

in the 5th paragraph, It should be :

" It is really rare not to be able to define the context of a method..."

# December 8, 2008 3:58 AM

Rabeeh Abla said:

This is good elaboration on this topic. I am getting feedback from other professionals in the field.

"I can only say that I agree. "Helper" is mostly laziness. Unfortunately, the J2EE patterns book introduced a pattern called "View Helper" and it may have contributed to the common use of the term. I never liked the pattern, finding the idea much too vague, but having had to use it sometimes."

Programmers in the field should practice on defining the role and responsibility of classes, functions and variables, etc... prior to using them, by using simple brainstorming and planning techniques.

Through experience programmers will be able to specify better role and responsibilities for {classes,functions,variables, etc…}.

# December 8, 2008 12:07 PM

Joseph Ghassan said:

' "Helper" is mostly laziness '. I totally agree with this statement.

Sometimes, you can't easily find a name for your class or your function because it performs an action that is too generic to define.

For laziness purposes, some programmers tend to tag the name helper to their functions or classes for the sake of it.

I prefer to create an anonymous function instead of naming it with the helper keyword.

# December 10, 2008 9:07 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)