- ベストアンサー
c#デリゲート関連の命名について
- c#デリゲート関連の命名についての質問です。SampleDelegateとSampleActionにはどのような名前をつければいいのか悩んでいます。
- SampleDelegateは値を取得するメソッドを表すので、'~すること'を表す動名詞を使用するのが適切です。SampleActionも同様に、値を取得することを表す名前にするとよいでしょう。
- 例えばSampleDelegateは'GetValue'、SampleActionは'ValueGetter'という名前を使うことができます。しかし、最終的な命名はコードの読みやすさや一貫性を保つことが重要です。
- みんなの回答 （27）
- 専門家の回答
質問者が選んだベストアンサー
＞結局、setとAddは結局同じ動作を含んでいたことに気づいて～ ＞何もデリゲートを使わなくてもやりたかったことの一部が出来たんです。 はい、そういう事ですね。 ＞_sampleAction( ←ここまで入れるとツールチップで変数名が表示されるので 或いはカーソルをかざしたりしても出てきますね。 こういうのをひっくるめてインテリセンス（Intellisense）というんですが VC++2008ではこいつがC#に比べてかなり貧弱なんですよｗ ずっと前にVC++で同じようなことしようと試みた事があるんですが、結局その時は どうあがいても、カーソルをかざすのか、キー入力だったかの、どっちか片方だけしか反映できないという結果だったように思いました。 （まぁ、「貧弱」というのはそれだけの理由では決してありませんが） 次のバージョンでは強化されたと小耳にはさんだので（もうさらにその次が既に触れられるのかな？）幾分期待はしていますが。 ・<>について たぶん見つかりました。 コレっぽい感じではないですか？ http://d.hatena.ne.jp/saiya_moebius/20090129/1233243475 html上でのあれとおんなじみたいですね < と > 使えば出来るっぽい感じです List<T> ↓ List<T> で、リンク先の方はこれだと書いてる側は分かり辛いってんで {}をかわりに使ってらっしゃる提案をされてますが それから、<include>使って別ファイルに置き変え出来るっぽいですね http://msdn.microsoft.com/ja-jp/library/9h8dy30z.aspx これを使えば、日英別々にxml作っといて、後で簡単に切り替えるといったことが出来るかもしれません。 私のとこでは dllにビルドしといて 別のC#アセンブリから 参照設定して(xmlファイルも運んどいて)呼び出したら 表示出来ました が 自分自身のアセンブリのとこに /// <include file='xml_include_tag.doc' path='MyDocs/MyMembers[@name="test"]/*' /> とかをやっただけでは出ず。 うーむ これが自分のとこでも反応してくれれば最強なんですが これは出来ないのかな？
その他の回答 (26)
- LongSecret
- ベストアンサー率68% (22/32)
すみません public ItemGettingCallback ItemGetter { get { return _itemGetter; } protected set { ItemGetter = value; } } ↓ public ItemGettingCallback ItemGetter { get { return _itemGetter; } protected set { _itemGetter = value; } } です。
- LongSecret
- ベストアンサー率68% (22/32)
>現在リファクタリングですが、なにせ多岐にわたって「protectedフィールド」を作ってしまったものですから根幹部分のクラスから修正中で、CList系には手を付けられていません。 >今回のものに関してはつい癖で「protected」としてしまっただけで、継承先ではまだ使用していません。 >可能性が十分にあるものとしています。 なるほど、そう言う状況ですか 命名を考えるにあたっては 十分に構造を把握しないといけないので （不要なメンバがある場合は前提が変わってくるなど） もうちょい確認させてください。 では、まず単純にこれらのフィールドをprivateにして置き private ItemGettingCallback _itemGetter; public ItemGettingCallback ItemGetter { get; set; } このパターンがもしベストなのであれば この_itemGetterが変更されるというのは ItemGetterのsetで行われることとする という風になると思われますが もしこの部分が継承先からしか変更されないとかなら、 public ItemGettingCallback ItemGetter { get { return _itemGetter; } protected set { ItemGetter = value; } } こんな風にもできますね（アクセス修飾子は可能な限り強力なものを優先できる構造にすると、後で修正や拡張が楽です。） もう少し このItemGettingCallback などのデリゲートですが これが「見えないといけない範囲」ってpublicじゃないといけませんか？ これらのコードから類推すると 最終的に、外部からはT（ジェネリック）1個だけ指定すればOKそうな気もしなくもないんですが
お礼
解答ありがとうございます。 > これが「見えないといけない範囲」ってpublicじゃないといけませんか？ CListActionBox<T>はその名前の通り本当に単なる入れ物でそのクラス内でnull対策などの適正化以外の処理は行われません。 使い方は // ------------------------------------------------- private CListActionBox<int> _itemActions; public CList<int> SampleItems { get { return _sampleItems; } } // ------------------------------------------------- などのようにして、クラス外部からでも、そのインスタンスを定義した場所と密接にかかわる部分で「CList」の「get」「set」を初めとする処理の変更を可能にするものです。そのため「protected set」にはできないと思います。 > このItemGettingCallbackなどのデリゲートですがこれが「見えないといけない範囲」ってpublicじゃないといけませんか？ 上記のように用いるため「public」にしないとアクセシビリティのエラーが発生します。
- LongSecret
- ベストアンサー率68% (22/32)
あー、意味分かんない箇所がｗ 正しくは CListActionBox<T>クラスか派生クラス CList<T>クラスの派生クラス ↓ CListActionBox<T>クラスの派生クラスか CList<T>クラスの派生クラス ですｗ
- LongSecret
- ベストアンサー率68% (22/32)
むむ？ CListActionBox<T>クラスの protected ItemGettingCallback _itemGetter; protected ItemSettingCallback _itemSetter; public class CList<T>クラスの protected readonly CListActionBox _actionBox; はフィールドですよね。 public ItemGettingCallback ItemGetter { get; set; } ↑こういうのがプロパティ フィールドがprotectedな場合は、下記の通り「_」ではじめるとCLS準拠じゃない 及び #7の ＞パブリック フィールドとプロテクト フィールドは適切にバージョン管理されず に引っかかってしまう恐れがあるので こいつらはprivateにしないとまずいかもしれません。 protectedでないといけない理由があるとしたらそれは「確実に派生クラスのコードに存在する」と思うので、 CListActionBox<T>クラスか派生クラス CList<T>クラスの派生クラス を、一つでも見せていただくことは可能ですか？（_itemGetterや_itemSetterや_actionBoxを使っている部分で良いです） また _itemGetter; _itemSetter; はreadonlyではないですが これは変更可能性がありますか？
お礼
> パブリック フィールドとプロテクト フィールドは適切にバージョン管理されずに引っかかってしまう恐れがあるのでこいつらはprivateにしないとまずいかもしれません。 現在リファクタリングですが、なにせ多岐にわたって「protectedフィールド」を作ってしまったものですから根幹部分のクラスから修正中で、CList系には手を付けられていません。 > protectedでないといけない理由があるとしたらそれは「確実に派生クラスのコードに存在する」と思うので、 今回のものに関してはつい癖で「protected」としてしまっただけで、継承先ではまだ使用していません。 > これは変更可能性がありますか？ 可能性が十分にあるものとしています。
- LongSecret
- ベストアンサー率68% (22/32)
ここでいうCLSはCommon Language Specificationのことですね ここに概要が集約されてるように思います。 言語間の相互運用性 http://msdn.microsoft.com/ja-jp/library/730f1wy3%28v=vs.80%29.aspx ＞どのようなプログラミング言語を使用しているコードからでも確実に利用できるマネージ コードを作成できるように、共通言語仕様 (CLS: Common Language Specification) と呼ばれる、各種の言語を利用する場合に必要とされる言語機能や規則のセットが定義されています。 つまり、Visual BasicからだろうがC#からだろうがC++/CLIからだろうが その他の、マネージコードをサポートする言語だろうが CLS準拠になっていれば 正式にサポートされてる、どの言語からでも使えるようなマネージコードのdllになる、ということです。（もしかしたら実際のところは不完全かもしれませんが、概念的には少なくともそう書いてあります） koumei000さんの過去質問をいくらか拝見させていただきましたが パフォーマンスを気にしてらっしゃる回もありましたね。 パフォーマンスを本当に求めたいなら 現状では、やはりネイティブなCやC++がだいぶ勝る場合が多いです。 で、C#からネイティブC++のdllを呼び出すとかも、可能は可能ですが、色々と不自由が付きまといます。 そこで、C++/CLIを橋渡しとして使う、といった手法があったりします。 C#側がメインでそこからC++/CLIを少し使う、といったことは現状でもできるでしょうが もし今作ってるC#のクラスライブラリがCLS準拠になってれば C++/CLIをメインにして、そっからC#のライブラリを安心して使う という手もその時自由に選択できるようになる、ということのはずです。 ＞ということは継承先で触る必要性のあるものに関しては「protected」プロパティにすれば良いということでしょうか？ はい、それで良いはずです。 ・コードについて とりあえず、ここまで書いて投稿しようとして その前に 別タブで確認して、お礼いただいたことに気付いたのですが 上記の内容が伝わるのは早い方が良いと思うので この回答は先に載せておきます 内容は今から確認しようと思うので ちょっと待ってくださいね。
お礼
早速の解答ありがとうございます。 > どのようなプログラミング言語を使用しているコードからでも確実に利用できるマネージ コードを作成できるように、共通言語仕様 (CLS: Common Language Specification) と呼ばれる、各種の言語を利用する場合に必要とされる言語機能や規則のセットが定義されています。 お恥ずかしいことにCLSをプログラミング言語の一種と勘違いしていました。勉強になります。 > パフォーマンスを本当に求めたいなら 確かにパフォーマンスは求めていますが、とりあえず、C++よりC#の方が簡単なので多言語への挑戦はC#でそこそこなってからにしておきます。
- LongSecret
- ベストアンサー率68% (22/32)
＞Yune-Kichiさん 確かに見返してみると 今回の要件では、あるいはCLS準拠の必要はないかもしれませんが このクラスライブラリがもし多言語から使われるなどなどといったことが今後想定される得るのであれば 準拠しておけるなら準拠しておいた方が確実、ですよね。 ＞CLS違反であるuintなどを使ってもprivateであればCLSCompliant(true)なクラスだったりします。 内部的に関数切り分けして、その部分は外には公開しないとかなら そこだけinternalにすればprivateまでいかなくてもOKですし (ていうか、CLS 準拠が関係する部分じゃないなら、もともとメソッドや型の命名規則とかもそんなに拘らなくてもいいんじゃないかなと。) CLS 準拠コードの記述 http://msdn.microsoft.com/ja-jp/library/bhc3fa7f%28v=vs.80%29.aspx それ以外については、やはりそうですね。 ここまでの内容を含めて、尚且つもう一歩進んだ命名法を考える というためには、とりあえずは 現状の継承構造とか、デリゲートになってる _sampleBox.SampleAction(); とか SampleBox とかの内容を見てみたいですね。
お礼
ご意見ありがとうございます。 思い返してみれば、継承時の高速化に拘りすぎて、あちこち「protected」だらけでむしろ「private」なんて構造体以外では見かけない状態でした。 >SampleBoxとかの内容を見てみたいですね。 とりあえず現段階での状態はこんな感じです。 // ---------------------------------------------- // これが「SampleBox」 // <summary> // Cは「Controled」の略。…</summary> public class CListActionBox<T> { // 実はこれが例の「SampleDelegate」。戻り値はTで、引数あり public delegate T ItemGettingCallback(int index); // ↓の二つが「SampleAction」 protected ItemGettingCallback _itemGetter; // 省略。setアクセサでは「value」が「null」時に既定動作の代入あり public ItemGettingCallback ItemGetter { get; set; } // set用もあったりする public delegate void ItemSettingCallback(int index, T item); protected ItemSettingCallback _itemSetter; // 省略。setアクセサでは「value」が「null」時の既定動作の代入あり public ItemSettingCallback ItemSetter { get; set; } // コンストラクタは省略 } // - - - - - - - - - - - - - - - - - - - - - - - - - /// <summary> /// Cは「Controled」の略。…</summary> public class CList<T> { protected readonly CListActionBox _actionBox; // ここが「public int Value」だった部分 public T this[int index] { get { return _actionBox.ItemGetter(index); } set { _actionBox.ItemSetter(index, value); } } // コンストラクタに「CListActionBox」の引数あり // その他は省略 } // ---------------------------------------------- こんな感じで至る所に「protectedフィールド」があります（省略した部分にも山ほど）。また、「CList<T>」は public CList<int> SampleItems { get { return _sampleItems; } } こんな感じで１クラスに複数使う予定です。 速度は計算量の問題なのは分かっていますが、一度プロパティとフィールド変数の速度の差を測定してしまってから至る所に「protectedフィールド」を使うようになってしまいました。 これらは「protectedプロパティ」に置き換えれば片付く問題なのでしょうか？
- Yune-Kichi
- ベストアンサー率74% (465/626)
MSのデバッグ用のリファレンスコードでも，_から始まるフィールドは使われています。 Reflectorで誤ってSystem.dllを見てしまったことがありますが，_から始まるフィールドがありました。 privateフィールドに関しては，_から始めて問題ないと思います。 元々，_から始まる識別子はC#に関してそれ自体は文法違反等ではないです。 CLSは別物ですし，CLS違反であるuintなどを使ってもprivateであればCLSCompliant(true)なクラスだったりします。 protectedフィールドに関しては，「それを定義したクラスが与り知らぬ場所で変更される」という点で，publicフィールドやグローバル変数と同じ問題があります。 それ故に，protectedフィールドは勧められません。 # MSDNの書き方はどうかと思いますが…… また，その理由から，constやreadonlyの修飾のなされたprotectedフィールドであれば同様のpublicフィールドと同じく，使用しても問題ないと思います。
お礼
解答ありがとうございます。 CLSってコマンドプロンプトの類ですよね？（間違っていたらすみません）たしかに、大文字と小文字の区別が無かったと思います。CLSに使うかどうか不明ですが、今後の役に立つと思います。 > protectedフィールドに関しては，「それを定義したクラスが与り知らぬ場所で変更される」という点で，publicフィールドやグローバル変数と同じ問題があります。それ故に，protectedフィールドは勧められません。 ということは継承先で触る必要性のあるものに関しては「protected」プロパティにすれば良いということでしょうか？
- LongSecret
- ベストアンサー率68% (22/32)
あ、これかな http://msdn.microsoft.com/ja-jp/library/x8ak87y5.aspx C#なら、フィールドの名前について private以外だとダメで privateならOK、っぽいですね。 どの道privateにしなきゃいけないってことなので、それを守る限りにおいて問題はない、が正解のようですね。
お礼
やっぱりprivateにしなければならないのですね。いろいろと勉強になりました。ありがとうございます。
- LongSecret
- ベストアンサー率68% (22/32)
一応確認してみました（C++) namespace だ、だめですよぅ{ struct AAAA { int _inline; }; int BBBB(int _fastcall){ return _fastcall; } } う～んｗ これに関しては、VC++2008で両方ダメでした。namespaceなくしてCでコンパイルしても通らない… まぁこれらは、青色になっちゃいますし、明らかに「こんなん書こうと思うなんて」あり得ないとはおもいますがｗ まぁでも、サンプルも結構あることだし C#のprivateなフィールドで 「_＋小文字スタート」は、「大抵は大丈夫」なのかなぁ
お礼
わざわざ確認してくださってありがとうございます。C++に移行する際の参考にさせてもらいます。
- LongSecret
- ベストアンサー率68% (22/32)
>「__」および「_+大文字」で始まる識別子は～たぶんこの辺は C# でも同じなんじゃないでしょうか. あ～！ なるほど、正確にはそういう風になっていたのですか。 それは大変失礼しました。 C++だと、連続して使うならちょー短い名前のローカルのポインタconst変数に移し替えることが多かったので「ぜってー使わん！」でも全然OKだったのですが。 C#だったらフィールドに前置き「_」使うとよさそうですね。 ＞ 残念ながら、その、ライブラリを作っているのです。 なるほど、そういう御用件でしたか ＞パブリック フィールドとプロテクト フィールドは適切にバージョン管理されず、またコード アクセス セキュリティ要求によって保護されません。 パブリックに参照可能なフィールドを使用する代わりにプライベート フィールドを使用し、それをプロパティを通じて公開してください。 そのまんまだと思います。 内部的に適切にバージョン管理されないようになってしまうので（どうしてそうなるかはMSしか知らないブラックボックスでも、問題ない） 公開するクラスライブラリのフィールドは 全部privateにしとけ、ということでしょう これは基本的なことですが 「局在性の高いもの」ほど 短い名前で済みやすいというのが挙げられます。 publicよりprotectedが、protectedよりprivateが メンバよりローカル変数のが 作用する相手は少なくて済むので、より短い名前で十分、というのはC、C++、C#すべて共通で言えると思います。 ローカル変数なんて、その関数内で使う数が少ないなど「実装者が十分バグフィックス楽なら」小文字１つでもOKなこともあります。
お礼
なるほど。勉強になりました。ありがとうございます。これから修正していきます。
お礼
ありがとうございます。おかげさまで大助かりです。 インテリセンスってオートコンプリートの事だけかと思っていました。あのツールチップもそうだったのですね。c#に慣れてきてたころに一度VC2010Expressに挑戦してみたのですが、「this->」の時点で意味が分からなくなった上、全然インテリセンスが表示されないのでいったん諦めて、しばらくはc#一本に絞ることにした覚えがあります。 「<include>」、覚えておきます。 初心者の長い質問に付き合ってくださって、ありがとうございました。