導入
C# を書いている皆さんに向けて、internalを使おう！！という話題です。
一応Unityを想定していますが、他の場面でも同様の話です。
ジャンルとしては、アクセスレベルです。
有名なアクセスレベル3種
| アクセスレベル | 説明 |
|---|---|
| public | どこからでもアクセス可能 |
| protected | 派生クラスからのみアクセス可能 |
| private | 自クラス・構造体内でのみアクセス可能 |
よく使われるのはこの3種ですね。
私は初学者の頃 protected の使い所が分からなかったのですが、継承なり抽象なりやっていくうちに、ダンダンと理解できました。
それで、個人制作の範疇ではそれで十分なのですが、
アセンブリを気にするレベルになってくると、少し不自由だったりします。
アセンブリ とは？
A. コンパイルされる単位です。
Unityだと、デフォルトでは全て Assembly-CSharp という名前のアセンブリにコンパイルされます。
外部アセンブリは見えません。
アセンブリ同士の参照関係を設定することで（Assembly definition）見えるようになります。
ライブラリ作成者はよく使っています。
internal
今回は、アセンブリを分割するべき！という主張は置いておいて、
とりあえずinternalに触れてみないか？ という趣旨で進めていきます。
internalの意味はこれだけです。
自アセンブリ内でのみアクセス可能
要するに、publicが少し厳しくなったものです。
外部アセンブリから見えなくなるので、勝手に使われないことが保証され、安心できます。
というわけで、
最初に述べた3種のアクセスレベル、あれを外部アセンブリから見えなくすると、こうなります。
＜ こんな感じ ＞
| アクセスレベル | どう進化するか | 説明 |
|---|---|---|
| public | internal |
自アセンブリ内でのみアクセス可能 |
| protected | private protected |
派生クラスかつ自アセンブリ内でのみアクセス可能 |
| private | なし | 自クラス・構造体内でのみアクセス可能 （元から internal の性質を持っている） |
一応 protected internal (派生クラスまたは自アセンブリ内でのみアクセス可能) というのもあるのですが、個人的にかなりマイナーだと思うので、飛ばしちゃいます。
まとめ
というわけで短いですが、
「普段使っているアクセス修飾子を置き換えてみませんか？」
という記事でした！