インターフェースの明示的実装
XMLコメントを書かないと警告がすごいことになる
開発現場って往々にして警告に対してもすごい敏感だったりする。
今の現場もそうで、「警告が一つでもあったら納品コードとして認めない」みたいな事を言っていらっしゃるのですが、一つ問題がある。
それはXMLコメントだ。
private以外のものに関してはXMLコメントを付けないと通常はコンパイラが警告として扱ってくるわけですが、インターフェース実装のクラスに対しても当然のように要求してくるのです。
Javaだと、インターフェース実装のクラスのコメントは書かなくてもJavaDocのツールが勝手に引っ張ってきてくれます。Eclipseだと勝手にリンクのコメント付けてくれたりするからなお楽。
でもVisual Studioにはそれが無い。。自分が知らないだけかもしれないが。
そんな訳で現時点でも警告は2000近く行ってるわけで、どうすんだろね。
明示的に実装するとコメントいらないらしい
先輩と話していたのだが、インターフェースを明示的に実装すると実装クラスではコメントがいらないようだ。
「これは便利だ!!」
とばかりに書き換え始めようとしたのだが、落とし穴があった。
インターフェースの明示的な実装をすると起こる事
インターフェースの明示的な実装は英語ではEIMI(Explicit Interface Method Implementation)と言うらしい、長ったらしいので今後はEIMIと表記するよ。
さて、ではEIMIを使う場面はどこなのだろう。それは、名前もシグネチャも同じメソッドを持つ複数のインターフェースを実装する場合だろう。
public interface A { void Execute(string arg); } public interface B { void Execute(string arg); } public class AB : A, B { void A.Execute(string arg) { Console.WriteLine("Execute A"); } void B.Execute(string arg) { Console.WriteLine("Execute B"); } }
実は、ジェネリックインターフェースがある現在では、EIMIを使うケースはこのケースのみで、これ以外では極力使わない方がよいらしい。
EIMIを使うと起こる悪影響
プログラミング .NET Framework 第2版によると、EIMIを使う事で起こる悪影響は以下の3つであると書いてあります。
- 型がEIMIメソッドをどのように実装しているか説明されているドキュメントがなく、Microsof Visual StudioのIntelliSenseも利用できない。
- 値型のインスタンスはインターフェースにキャストすつときにボックス化される
- EIMIは派生型から呼び出せない
詳細な説明は書籍を一読してもらうとして、まず1の影響は顕著でした。Visual Studioで開いているクラスのメソッド一覧を出すドロップダウンにEIMIのメソッドが出てこない!これは本当に焦りました、一瞬消してしまったのかと。。
2は個人的には遭遇する事はあまり無いのですが、このドキュメントを読んで、やっとC#が「インターフェース経由でインターフェースのメソッドを呼ぶ」というのをやらせたがるのか分かりました。
Javaから来た自分としては、なぜわざわざ「インターフェース経由」で呼ばなければならないのかさっぱりわからなかったのです。
というか、今でも「C#はインターフェースを重視していない言語」って思ってしまいます。だって、List
結局XMLコメントの問題は解決しない
結局EIMIでのコメントの省略の夢は潰えました。。
確かにコメントは無いよりあった方がいいとは思いますが、結局実装クラスに書くコメントってほとんどの人がインターフェースのコメントのコピーで、しかもそのコメントはほとんど意味の無いものばかり。
だったら、付けない方がまだマシ。
もちろん過密スケジュールでまともにインターフェース設計もできないような状況でインターフェースに細かく事前条件やらを書いていくのは1実装者としてキツイです。てゆうか自分もできてない。。
管理者の方は「警告があったら納品物として認めない」とか言うのは簡単だけど、ホントに必要なものと無くてもいいものをちゃんと見極めて指示を出して欲しいな〜。
written by dany (role of younger brother)