2013-10-18 7 views
12

String.Split overloadという質問に対しては、StringSplitOptions列挙型をパラメータとして使用します。C#でのenumパラメータへのアクセスを制限するためのベストプラクティス

enum自体が公開されていて、System名前空間を含むすべてのものにアクセスできるのは悪いことではありませんか?つまり、列挙型はSplitメソッドのオプションに完全に固有ですが、その範囲外でも使用できます。

おそらく、列挙型をStringクラス自体に入れて、String.SplitOptionsを使用してアクセスするなど、これをモデル化するより良い方法がありますか?私は非常にめったにこれを見ません(私は実際にそのような場合は今思い出すことができません)ので、それは何らかの理由で好まれていないと仮定します。一般的に、私は物事の範囲を縮小することがベストプラクティスであると考えています。なぜなら、誤ったスコープのクラス/メンバーを使用することによって問題が発生する可能性を低くするためです。

ここでは例としてSplitを使用していますが、Enumはコードベースのメソッドまたはクラスでのみ使用するのが一般的です。私は一般的に他のクラスと同様に別のCSファイルにパブリック型として列挙型を作成しますが、私はこの「問題」に対する他のアプローチを聞きたいと思います。

更新:

私はちょうどFolderクラスとFilter列挙して、この正確な問題を攻撃this articleが見つかりましたが、再び(内部列挙型を置く私はそのような場合には、より正確であると信じて何に反しているようですどういうわけかクラス)。 ToddMからそこでのコメントの一つ(私は同意するが起こるいる)状態:

...

しかし、その後も、私はあなたのロジックが間違っている気がします。あなたの主な苦情 クラスの中に列挙型を埋め込むことは、入力するのに長すぎる がかかることです。どのくらい冗長なC#があるかを考えれば、これは実際には ではありません。 VSでは、CTRL + SPACEはあなたの友人です。

論理的には、クラス内の列挙型を配置するのがはるかに多い です。あなたの例を挙げる:MyNameSpace.Filterとは何ですか? はどこに適用されますか?私はそれがあなたの名前空間のフィルタだと思いますか? には不可能です。特に、名前空間が拡大して何十ものクラスが含まれている場合は特にそうです。

今MyNameSpace.Folder.Filterを考える - それははるかに 直感的にそのフィルターが フォルダクラスにいくつかの方法、形状、またはフォームに適用され、私の心の中で、あります。実際には、別のクラスを 独自のフィルタの概念で名前空間に追加することができます。そのメンバーの1つは「ファイル」です。ちょうど あなたが新しいクラスをネームスペースに導入したので、 には、その名前空間をさまざまな「ヘルパー」タイプで汚染する権利が与えられていません。 大規模な開発チームの一員として開発している場合、あなたのスタイル は、まあ、失礼です。

...

+2

enumをクラススコープ内に置くと、それ以外の場所でも使用できます。クラスに対してプライベートにすると、それをクラスのメソッドのパラメータとして使用することはできません。 – Peter

+1

このようなネストされたタイプが好きです。それはあなたのインテリセンスを圧倒しておらず、またより良い意味を与えます。しかし、多くの内部MSはそれを好きではありません... – nawfal

+0

あなたの更新された質問からリンクされた記事に対する議論:読みやすさのために、私は 'Folder.BlaBla(Folder.Filter.Bla)'ではなく 'Folder' BlaBla(Filter.Bla) 'と表示されます。唯一の悪い点は、それがインテリセンスを汚染することです。しかし、それは 'Filter'がある他のものがあるときにのみ起こります。チャンスはそれが起こるスリムです。 – Bas

答えて

0

String.Split()は公開され、そのStringSplitOptionsはあまりにも公共なければなりません。 System名前空間にはStringStringSplitOptionsの両方が存在します。どちらも公共の範囲を持っています。どちらも "他の範囲外で利用可能"ではありません。

+1

私は 'String'クラスそのものの範囲外であることを意味しました。混乱して申し訳ありません。 – julealgon

7

enumを入れ子にして、範囲が狭いことを示唆するか、より良いセマンティクスを与えることは興味深い考えです。私はこのアイデアを使用して、後のコンパイラI developedにエラーコードと警告コードの両方を持たせました。このようにして、同じエニューム名CodeError classまたはWarning classのいずれかにネストすることができます。

一方、パブリックネストされたタイプは一般に推奨されません。彼らは外部のクラス名でそれらを修飾しなければならないクライアントに混乱することができます。関連するガイドラインon MSDNを見てください。関連するもの:

論理グループ化構造としてパブリックネスト型を使用しないでください。このために名前空間を使用します。

公開されているネストされた型をAVOIDで示します。唯一の例外は、ネストされた型の変数を、サブクラス化やその他の高度なカスタマイズシナリオのようなまれなシナリオでのみ宣言する必要がある場合です。

型が包含型の外部で参照される可能性がある場合は、入れ子型を使用しないでください。

たとえば、クラスで定義されたメソッドに渡された列挙型は、クラス内でネストされた型として定義されるべきではありません。

これらのガイドラインは、StringSplitOptionsエニュームとBCLの他のほとんどを開発する際に従っていると思います。

+1

実際のMSDNガイドラインのお見積もりに感謝します。私はこの特定のものを見たことがないと思うし、おそらくそれを過ぎ去ったかもしれない。 – julealgon

0

理由の1つは、埋め込まれた列挙型を使用してすべての呼び出しを行うという理由の1つと考えられます(クラス名は必須プレフィックスになります)。

この列挙体を使用する必要があるたびに、私は個人的にResultSetTransformer.ResultSetTransformerOptionsを使用しなければならないことを感謝しません。それは私の行をひどく長くするでしょう。

しかし、他の人が指摘しているように、おそらくこの理由のために、クラスに列挙型を埋め込むのがフレームワークの標準だとは思えません。

+2

代わりに 'ResultSetTransformer.Options'はどうでしょうか?また、なぜそのエイリアスが問題になるのでしょうか?別名で列挙型にもアクセスできないでしょうか? – julealgon

+1

あなたはResultSetTransformerについて正しくあります。オプションは、私はちょうど今より良い例を考えることができませんでしたが、ポイントはあなたが広いクラス名を持っている場合は、あなたの呼び出しでそれを使用する必要があり、より多くの場所を取るだろうということです。 また、文字列のエイリアスについては、この引数が非常に弱いため、大文字で小文字の文字列を使用すると矛盾しますが、それを削除しますが、他の場合は完全に可能です...) – igelineau

関連する問題