Package org.moyoman.helper

Provides classes used in creating helper classes.

See:
Description

Class Summary

Helper	The base class for all helpers in the system.
HelperConfig	Read and write configuration information related to helpers.
HelperConfigTool	This application provides the user with an interface for editing the helper configuration files.
HelperName	This class represents a helper name, e.g, org.moyoman.helper.joseki.dictionary.dict1.Dict1.
HelperType	This class represents a helper type, e.g, RulesHelper.

Package org.moyoman.helper Description

Provides classes used in creating helper classes. Helper classes exists at different levels of generality. Some helper classes might be used by any module, while others are specific to a given module, such as the dictionary helper for the joseki module. Still other helpers are still more specific. For example, there is a rules helper for the Board module. There may also be a JapaneseRules helper, ChineseRules helper, etc.

Examples of helper classes would be rules for the board module, and dictionary for the joseki module.

The reason for making rules a helper is that the board can determine what type of rules the game is being played under and hide that complexity from the users of the board module.

The reason that dictionary is a helper is that most implementers of joseki modules are going to have a component that finds the book move, and another component that finds moves if the opponent plays out of the book. When a component of a module can be standardized like this, then it should be made a helper so that different joseki module writers can reuse the component for finding the book move, while customizing the out of book component.

The package layout for helpers can vary. For example, implementations of the dictionary for joseki would be packages under org.moyoman.helper.joseki.dictionary. However, there might be helpers that would contain different subtypes as well. The implementations of the Japanese rule set could be a package under org.moyoman.helper.board.rules.japanese.

It is somewhat arbitrary what is made into a helper, since the out of book component of joseki could also be a helper. A good rule of thumb is that if a component is fairly standard, is important to the program as a whole, and takes a fair amount of effort to implement, then it is a good candidate.

The reason for not just making dictionary and outofbook into modules of their own is that the caller is not interested in them, and just wants suggestions for moves in the corner. If the dictionary and outofbook code are each made into helpers, then the code in the joseki module becomes primarily just code to use the output of the two helper modules. Competing implementations would then occur primarily at the helper level, not the module level. Of course, it is also possible for the module to perform more sophisticated analysis, such as comparing the outputs of each of the helpers and trying to reconcile them if they don't agree.

A module developer is not required to use the helpers for that module. For example, a joseki module could be written using neural networks, and would have no use for the dictionary helper. It is merely a resource that is available to the module developer.

Author:

David Weiss.