クラスというものを部署として捉えてみたらわかりやすいんじゃないか？と思いつきました。（『設計図』では説明できない部分を説明できる？）
初心者はクラスは無視すべし！
クラスというものは、使いこなすのが一番難しい要素のようです。
オブジェクト志向という、初心者がその意図をつかみ辛い概念とその思想の柱となる“クラス”。こちら第一回は、別に初心者はそれらを意識しなくてもよくね？という提起をしてみました。
クラスなんかより、初心者はもっと変数の宣言やそのスコープ、寿命とか配列や、for文、if文などのもっと基本的なことの理解、あるいは単純なものでいいから自分でプログラムを書く、ということに集中したほうがいいのではないか？というものでした。
今回も“クラス”についてで、その捉え方についての自分なりの考えをまとめてみます。
クラスは結局、何なのか？
Random rand = new Random();
という感じでnewを使って宣言するのが基本です。
Unityにおける他クラスへのアクセスはどうやるかというといろんな方法があって、ぶつかったcolliderから引っ張ってきたり、タグからそのスクリプトがattachされたオブジェクトを探してそこから引っ張ったり、あるいはpublicなオブジェクトとして、直接そのオブジェクトをinspecterに引っ張ってきたりしてきたものを、インスタンスに入れる、といろいろな方法があるわけで、それはそれでそのうちまとめたいと思います。
単純に考えれば、ある設計図で他の設計図を利用する際には一手間かかる、ということです。設計図に例えるのはあくまでイメージするための方便に過ぎないと思います。
この一手間をはじめとして“クラス”における『なぜ？』を説明するのに設計図という例えは弱い気がしました。
Unityにおいて"Script"を新規作成する、ということはクラスを作るということだと思います。new演算子は基本的には使わないのです。
なのでクラスを作るということを意識するでもなく、無意識にどんどんやっていくことになります。でもプログラミングという点に絞れば“クラス”を作るということは決して必須ではないですし、そもそも補助的な機能です。自分も含めたプログラム初心者にとっては、認識のズレは落とし穴になるのではないか？と思います。
もちろん“クラス”という概念ナシにはUnityを含め、現代的なプログラミングは不可能なわけで、なおさらきちんと理解する必要があると思います。
上手く例えられるものがあるか？と悩んでいました。
クラスは一体どんなもの？
では“クラス”というものをどう捉えるべきか？
ということを考えていきたいと思います。
クラスといえば、あらゆる書籍において『設計図』のようなものと説明されます。猫でもわかる～とかでもそうだったはずです。気をつけなければいけないのは、プログラミングにおける様々な概念は、見立てによって成立している、ということです。
- プログラミング言語は、機械と話すための言葉
- 変数は、データを保存するための器
- 関数は、ある処理をする機械、工場
- クラスは、設計図のようなもの
これらは、結局はコード上というかIDEやエディタ上でのみ存在する、架空の存在で実在はしていないということです。人間にとってわかりやすくするために、ある、と考えると便利だよね、というものです。
クラスは確かに設計図としての側面はあるでしょう。しかしそれだけではうまく説明できない部分もあるんじゃないか？と自分は思うわけで、個人的になにかもっといい例えがないのかと考えていたわけです。
設計図とすると何が問題か？
クラスは上記記事にも書きましたが、セクション毎に分けて書くことで読みやすくなる、管理しやすくなる。という利点があり、必要な情報や道具、処理の手順などがまとめられています。
そう考えると確かに設計図です。
それぞれ設計図があって、必要なものの実体を作って、実際の動作をその実体を通して行う、ということがオブジェクト志向の基本だと思います。
ただし、CUIならstatic void mainがある場所、またGUIアプリであるならメインのformがある場所もまたクラスの中にあるのです。
static void Mainがプログラムの本道となる部分。Programクラスの中に囲われています。
設計図の上で、実際の動作が起こるのでしょうか？
例えば、自動車のクラスがあったとして、他のクラスでそれを動作させる時は、その他のクラス上において、自動車のクラスに基づいて実際の車を作成、動作させる、ということになるわけです。
しかし設計図の上で、車を動かすの？となってしまいます。こういう風に考えちゃうとクラスを設計図と例えるのはどうなんだろうと思っちゃうんですよね。
クラスというくらいですから学校のクラスに例えるのはどうか？ですが基本的には学校のクラスは平均的に分けられたものですので機能的にそぐわないと思いました。
担当部署はどこですか？
それで最近思ったのは、部署に例えるのはどうか！ということです。会社でもいいですし、役所でもいいと思います。
これなら担当部署ということで機能毎に、役割がそれぞれ違う部署がいろいろあるということが、“クラス”というものの機能に沿って、自然に説明できるような気がします。
プロパティも“窓口”なわけですよ。ここを通して設定したり資料（データ）を受け取ったりするわけです。
まず本部があるわけです。つまり実際の動作、処理の中心となるクラスです。主要な処理や動作はここで行われます。別に本部だけで済むならそこで済ませればいいんです。
仕事の規模が大きくなれば、それに応じていろんな専門部署が作られます。部署には担当する分野の様々な資料、設計図（データメンバ）や特定の機能をもつ機械（関数メンバ）が補完されています。
もしそれらの専門部署の機能や部品が必要な場合はどうするか？直接使うことは出来ません。許可がなければ持ち出すことは出来ないのです。
（アクセス権の問題）
実体のあるモノを作って本部に持ってきてもらう、でもいいですが、その部署から職員にきてもらって、いろいろ仕事してもらう、と。
クラスを作る、というのはある意味で役割分担なわけですからね。インスタンス、オブジェクト生成はこのように例えるとイメージが湧きやすいんじゃないかと、思うんですがどうでしょうか？
インスタンスを作る、原型から実体を作る、ではなく
例えばRandom部のrandさんに本部に来てもらって乱数を作ってもらうと。
Random rand = new Random();
「randさんを呼びだして、本部に来てもらおう！」
int ransuu = rand.Next();
『randは呪文Next();を唱え、乱数を作り出した！』
みたいな。
これわかりやすくないっすか？どうっすかね？
