連載：［完全版］究極のC#プログラミング Chapter11　フレンドアセンブリ 川俣 晶 2010/01/18
Page1 Page2

11.2 そもそも、アクセスを制限する価値とは？

　このようなアクセス制限の価値がいまひとつわからない読者も多いだろう。

　どうせ呼び出さないクラスやメソッドがいくら増えても、呼び出さなければ影響はないというのも1つの考えだろう。もちろん、コードを書き換えたときに名前の衝突という問題が起きやすくなるが、それは深刻な問題ではない……と考えることもできるだろう。名前など、書き換えてしまえばどうとでもなるのである。

　しかし、これらはいざ問題を起こすと深刻で底深いトラブルとなることがあり、避けられるものなら避けたほうが、保守性や生産性が高くなるものである。

　だが、それよりも、もっと明確なメリットがある。

　Visual StudioのIntelliSense（インテリセンス）に大量に出てくる候補を減らし、目的の名前を探しやすくできるのだ。たとえば、上記の例でいえば、Program.csでIntelliSenseを機能させてもInternalClassという名前は出ない。もし、フレンドアセンブリを使わず、public指定を使っていたなら、IntelliSenseの候補にInternalClassが出てしまうのである。

　もちろん、1つぐらいならどうということはないが、実用プログラムで数十、数百のクラスが絡み合っているとき、IntelliSenseに出てくる名前を大幅に減らせることは大いなるメリットといえるのではないだろうか？

【Exercise】練習問題

　フレンドアセンブリについて間違ったことを述べているのはどれか？

1. InternalsVisibleTo属性を使う
2. 単体テストで役立つかもしれない
3. アセンブリを単位にした指定である
4. フレンドアセンブリの関係を結んだ2つのアセンブリの立場は対等である
5. インテリセンスで表示される項目数を減らすかもしれない

　◎解答：「4」（この行をマウスで選択してください）

INDEX
	［完全版］究極のC#プログラミング
	Chapter11　フレンドアセンブリ
	1．11.1 アセンブリ内部のメンバーへのアクセスを許す
	2．11.2 そもそも、アクセスを制限する価値とは？／練習問題

　

「［完全版］究極のC#プログラミング」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）