This pattern is unrestricted; it is used within any architectural layer.
A PED Helper contains supporting logic. A typical force promoting use of this pattern is a desire to aggregate reusable functions; thus eliminating duplicate code within invoking classes. An additional force may simply be the avoidance of code bloat within a single invoking class or enhanced design cohesion.
Helper classes have an additional role within frameworks. They enable direct invocation of a function that might otherwise be wrapped with an API intended for use via inheritance, composition or annotation. That is, this pattern facilitates framework composability.
- using an Enum for worker-thread safety
- ensuring that any Helper cache (state) is worker-thread safe
Classes containing cache are specifically addressed by Joshua Bloch (Effective Java: 2nd Edition):
“Unless you have a compelling reason to do otherwise, use ConcurrentHashMap in preference to Collections.synchronizedMap or Hashtable.”
The clever use of static and instance methods can enhance public API clarity for a developer using code completion within an IDE. A static method is immediately visible with Content Assist…
… whereas an instance method can be labelled “INTERNAL” to communicate limited public use:
JndiContextCacheHelper.INTERNAL.bind(ldapName, new Object());
When using a Helper consider these suffix variants for expressive readability:
- …UtilHelper [Stateless]
- …CacheHelper [Stateful]
|Extend Base Class||N|
|Static Public Methods (enum)||Y|
|Delegate to Helper||Y|
- By convention state may be coded as static to express intent.
- Ensure that cached objects are atomic.