>> Regarding the enums, we did consider them in several places but they prevent
>> addition of new constants by the framework or by the developer, especially
>> without breaking existing code. They also produce extra artifacts in the
>> Javadocs cluttering them.
Regarding enums and extensibility, this pattern works quite well:
interface MatchMode;
enum RouterMatchMode implements MatchMode {
BEST,
CUSTOM,
FIRST,
LAST,
NEXT,
RANDOM,
;
}
void Router::setDefaultMatchingMode(MatchMode mode);
Then a developer wanting to extend the match mode need only implement
the marker interface MatchMode on their new enum and they are
interchangable with those provided by the library. This implementation
style also makes it easier to extend the match modes because you don't
have to sit around thinking and double checking, "now should my new
mode be index 5 or is that used by one in the lib already?"
<twoCents>
For me, robust design patterns that prevent foul play and
encourage responsible design are always preferable to saving some room
in the docs.
</twoCents>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2416635
