このクラスの利点は、割り当て/構築時に不正な文字列を自動的にフィルタリングできることです。また、ファイル名を表すために想定されている文字列だけでなく、ファイル名を処理していることを絶対に確信できるようになります。
クラスの問題は、どこに制限があるのかということです。不要なクラスの膨大な品揃えを作成することになりますか？たとえば、一部の文字列はx文字とy文字の間にのみ存在する必要があります。それらのためにクラスを作るべきですか？
URLのクラスはどうですか？または、大文字の文字列のみのクラスですか？どこに線を引くのですか？
ありがとう。
それは文脈に依存します。ほとんどのアプリケーションでは、あなたが与える理由のために、そしてまたあなたが扱っているAPIがとにかくファイル名が文字列であることを期待しているのであなたは気にしないでしょう（そして有効なファイル名をチェックすることに何か利点がありますか？多分あなたは見るでしょうそれを使おうとすると適切なエラーが発生し、システムライブラリ内のそのコードは、さまざまなプラットフォームに適応します。これについては、知らないか、テストしていない可能性があります...）。
ただし、ディレクトリとファイルの違いを知ることが重要な場合（クラスはタイプレベルで区別を示すことができます）、またはファイル関連の情報がたくさん必要な場合（クラスこれを収集するのに適した場所です）またはファイル名に対して特定の操作を実行するときの高性能（クラスは結果をキャッシュすることでパフォーマンスを向上させることができます）など。
したがって、最良の設計は、あなたが何をしているかに正確に依存します。システムに大文字の文字列のみを含めることが重要ですか？使用しているネットワークライブラリにURLがすでに含まれていませんか？コンテキストがすべてです...
単なる文字列ではなく、オブジェクトの観点から考えてみてください。文字列は何を表していますか? クラスよりも単語やフレーズ以上のものを表す場合、おそらく意味があります。
FileName クラスを定義するのではなく、実際のファイルを表す File クラスを定義します。FileName は単にそのクラスのプロパティになります (その場合、ファイル名の検証をクラスに入れることができます)。また、Open()、Write()、Close()、Read()、PathName などの便利な関連プロパティとメソッドを組み込む機会も提供します。
同様に、おそらく文字列から抽出したい他の詳細があるため、Url のクラスは理にかなっています。例: ホスト名、ポート、クエリ文字列。クラスにすることで、このすべての機能を 1 つの場所にまとめることができます。