If the set is small (like the set of weekday names) then it doesn't really make a difference--hashset works. If the possible matches have some overlap, the asymptotically best matcher is a finite state machine (look up finite automata if you really care).
If you consider the days of the week, there is some redundancy. 'Saturday' and 'Sunday' both start with S. An optimal finite state machine would hardcode the logic, "If the first letter is S than the next letter must be either 'a' or 'u'. If 'a', it's Saturday, if 'u' it's Sunday". It would then check that the rest of the Strings is the expected sequence ('turday' or 'nday' respectively).
The benifit in this situation is so little that the overhead of dealing with the state machine isn't worthwhile. It will always run in O(n), but using a HashSet should also get you O(n) running time unless there are hashcode collisions. In the worst possible case, which shouldn't ever happen with Strings, all the hashcodes are the same and the HashSet solution runs in O(n^2) time--it would be equivelent to storing every item in an array and checking them sequentially. A hashtable that used a binary tree to handle collisions could ensure O(n lg n) performance. Actually you could just use a sorted array and do a plain old comparison binary search in O(lg n) time. That would be the best solution, except that upper bound doesn't take into account the fact that String comparison is O(n), so it really works out to O(n lg n) anyway. The automata win in the end. Hmmmm. I'm rambling.
Things like finite automata are mostly useful for more complex matching problems (for instance, checking for a substring rather than an exact match).
Unless you find this sort of thing interesting or have a more complex matching problem to solve, this post was probably a waste of your time--but I kept myself amused by writing it
.
What I should have said instead of all this nonsense: Use a HashSet, as Ilja suggested. Problem solved.
[ January 07, 2003: Message edited by: David Weitzman ]