「クラス」の考え方のひとつ 01/09 木

　今まで C++ を使っていて、最近になって C# を使うようになって、やはりひっかかったのがクラスの考え方です。

　Visual Stidio 2019 では、あらかじめ「ひな形」が用意されているので、「だいたいこんな感じのものが作りたい」と考えたときには、その原型になるようなものは、ボタンひとつで作ることができます。

　しかし、そこから先、自分の意図するものを作るためには、プログラミングが必要です。このとき、「基本的にどのように考えればよいのか」が分かっているか否かで、作業効率が大きく異なります。

　「基本的にどのように考えればよいか」は、基本的な考え方ですから、わかってしまえば、まさに基本的なので、あたりまえのことになってしまいます。しかし、わかるまでの間は、逆に、基本的すぎて、「いったい、何がなんだか、全然わからない」という状態になります。

　おそらく、検索しても、あまりこういう情報がひっかかってこないのは、「分かってしまえば当たり前なので書く必要がない」、「分かるまでは、全然わからないので、書きようがない」ということなのではないかと思います。

クラスは設計図である。そして C# にはクラスしかない

　いろいろなサイトを眺めていて、私自身が一番「なるほど、そういうことか」と感じたのが、上の文章です。

　クラスというのは、設計図である。設計図であるから、プログラムしている時点では、まだ実物は存在しない。したがって、なにか「あるもの」が最初から存在すると想定してプログラムしようとすると、行き詰まってしまう。 

ということだと思います。

　昨日のブログでも書いたとおり、クラスを使いたいと考えるのは、「ひとつのものに、たくさんの部品や属性があって、ゴチャゴチャしてしまうので、それらの部品や属性をひとつのものとしてまとめてしまおう」という場面だと思います。この、「ひとつのもの」というのが、プログラム全体で一種類しかなければ、そんなに問題になりません。

　ところが、「こういうゴチャゴチャ」と「ああいうゴチャゴチャ」があって、それぞれ、ひとつのものとしてまとめたいと考えます。これらのゴチャゴチャは、全体としてひとつのプログラムになっていくのですから、当然、相互に関係しています。ところが、「こっちのゴチャゴチャ」も、「あっちのゴチャゴチャ」も、それぞれが設計図ですから、まだ実物がありません。

　こっちのゴチャゴチャで、こういうことをしたい（こういうことが想定されるから、こういう作業をしたい）という場面で、「じゃあ、あっちのゴチャゴチャの、この部分も一緒に変更しよう」と考えると、「それは、まだ実物がないから、触れないですよ」と叱られます。

　仕方がないので、じゃあ、あっちのゴチャゴチャを先に処理して、その後で、こっちを処理しようとすると、「こっちは設計図だから、触れません」と言われます。

　じゃあ、どちらも設計図なんだから、それらの設計図にしたがって組み立てる前に、あらかじめ共通のものをつくっておけば、両方からアクセスできて良いんじゃないだろうか、と考えると、「 C# は、クラスしか認めていないので、あらかじめ共通のものをつくることはできません」と言われます。

いったいどうすればいいんだー

　と思うわけですが、一応、逃げ道があって、

    static public 型名 変数名;

というものを使います。「static」は「静的な」という意味で、「public」は、「他のクラスからも見ることができて、アクセス可能な」という意味です。このうち、「静的な」という部分が肝心で、「設計図を書く段階で、この静的なモノについては、あらかじめ実物を用意しておく」という意味になります。したがって、「実物がちゃんとある」、「他のクラスの設計図からもアクセスできる」ということになるので、めでたし、めでたしということになります。

　ほとんどの「モノ」は、プログラムを実行する場面までは設計図のままで、本当に実行するときに、ちょっとだけ実物をつくって、すぐに廃棄してしまう。そうすれば、余計なスペースは必要なくて、効率よく作業ができる。そして、本当にプログラム全体で共有しなければならないものだけを、「わざわざ、static public という形容詞をくっつけて」あらかじめ実物をつくっておく。というのが、C# の基本的な考え方なんだなあと、思いました。