trie データ構造 (google it) を使用すると、単語を効率的に見つけることができ、複数形やその他の時制を保存するコストは無視できます。
トライは、ルート ノードから始まるツリー構造です。すべての子は文字で索引付けされるため、すべてのノードはこの時点までの単語に対応します。各ノードのフラグは、これが完全な単語かどうかを示します。
「車」のような単語を見つけるには、ルートから開始し、C リンクをノードに交差させ、次に A リンクを次のノードに交差させ、次に R リンクを次のノードに交差させます。この時点で、ノードは完全な単語 (CAR) としてマークされていますが、完全な単語としてマークされている CARS を表すノードへの S リンクを横断することもできます。
いくつかのグーグル検索の後、これを行うクラスを見つけることができませんでしたが、できることは、パラメーターの一部として単語を使用して、dictionary.com などの Web サイトを呼び出すことです。html をスクレイプして、単語が実際に存在するかどうかを確認します。
この辞書は Java サイトで見つけました。たとえば、「Official Scrabble」の単語リストと比較すると、それがどれほど「良い」かわかりません。
Trie データ構造はやり過ぎかもしれません。私自身、まだ試していません。(駄洒落は避けられないようです。申し訳ありません。) 単語を数値形式に変換し (ただし、文字列の hashCode は問題ないかもしれません)、それらをハッシュセットに格納することを検討してください。ハッシュ SET と言うのは、本当に知っておく必要があるのはメンバーシップだけだからです。リストのメンバーが存在するかどうかをテストするために私が知っている最も簡単な方法は、それを HashSet に追加することです。失敗した場合、それは既にメンバーです。成功した場合、それは単語ではなく、削除することを忘れないでください!
私はこのプログラミング戦略を使用して、Boggle のさまざまな側面をいじり、特定の Boggle キューブを考慮して単語頻度のリストを作成しました。
検索に関連する構造がある場合、たとえば、ランダム アクセスではなく、特定の順序で検索することがわかっている場合は、トライのようなより構造化されたアプローチが最適化に適しています。しかし、ターンベースの単語ゲームでは、驚異的なパフォーマンスはほとんど必要ないことも考慮してください。（接吻）
質問に反対票を投じるなんて不機嫌です！私がこの問題に最初に取り組んだとき、この問題に注目を集めるのは難しいと感じたので、元のポスターにはいくらか同情しています。これを相殺するために、質問に+1を付けています。