【学び】オブジェクト指向ってナニ?(1)
C++やJava言語の神髄、そして学校でも習う「Scratch（スクラッチ）」でも感じられるプログラム（ソフトウェア、以下ソフト）を作る際の考え方に「オブジェクト指向」があります。
「オブジェクト指向」の考え方の基本は、令和の時代になっても変わっていません。漢字が違う「思考」と捉えていいくらい、プログラミング（プログラムを作っていくこと）のスタイルを激変させました。しかし「オブジェクト指向」は、底なし沼ほどに奥が深いため、パニックとなって、オブジェクト指向の考えが不要な、他のプログラミング言語（日本語、英語、ドイツ語のように色々な言語があります）へと去ってしまう人も少なくありません。
そんな「パニック」を解消していくのが、この記事の目的です。
まず、今では「オブジェクト指向」を使った、もしくは、一部に取り入れたプログラミング・スタイルが一般的で、かなり敷居が下がっている現状があります。そして「オブジェクト指向」もアレンジや改善され「まぁ、なんとなく理解できて……」さえいれば、それなりに便利に使える具合となってきました。
次に「オブジェクト指向」を堅苦しく表現・定義すれば「データ（変数）とそれらを使って処理をするプログラム（関数：小さな処理用プログラム）は、これまでバラバラに存在していた。それらを、データ（変数）を土台にして、各種処理（関数）を、とっかえ引っかえし、ワンセット（＝クラスと呼びます）にしたもの。これらクラスを作り、使っていき、大きなプログラムを完成させていくスタイル」。こうなるでしょうか。
上は普通にプログラミングするイメージ
下は「オブジェクト指向」に従ってプログラミングするイメージ
では続けます。データ（変数）に対し、どんな処理が必要か考え、関数をプログラミング（記述）します。関数にはどんな機能・処理をするかわかるような名前「関数名」をつけます。それら（複数の）関数を含め、まとめたものが「クラス」でした。
この「クラス」はもはや、かなりの処理が行える完成したプログラム同様の記述です。さらに、オブジェクト指向のプログラミングでは、クラス同士を合体ロボのごとく組み合わせて調整し、ひとつの大きなプログラム（誰もが動かせるアプリや応用ソフトウェア）へと、仕上げていきます。
そのうえ、クラスの記述をコピーして、ちょっと改装して使えます。一度作ったクラスの使いまわしです。これができるため「プログラムを作っていく＝プログラミングの工数を（時間も）大幅に減らす救世主」となるケースも多々、あります。大きなメリットです。
似たようなこと、文書でやった方は多いのでは？ そう、コピー＆ペーストです。略称コピペに近いプログラミング（うまく組み込めるかどうかは、腕の見せ所）ができるため「オブジェクト指向って、何だかスゲー。他の人が作ってた機能（関数）まで使いまわせるぞー」となっています。ただ、デメリットは最初のハードル（クラスを作って何かしらプログラムを完成させてみること）が高い点。
と、おそらく「うんちくはいいからクラスがスゴイってとこ、早く見せて！」などなど、リクエストされていると思います。
でしたら、もしプログラミングして作っている制作物がFPS系のゲーム（弾を撃ちまくるシューティングゲーム系）だとしたら、クラスはどう活かす？？
それっぽい名前「Dragon」として作ったDragonクラスに、指示を色々と加えていきます。クラスにゲームを操作するのに必要な、データや対応する処理（関数）をプログラミングしていきます。
これでクラスの機能を活かせる、オブジェクトを完成させられます。この説明では混乱しますので、厳密には微妙ですけれど、「クラス＝オブジェクトの素」と考えた方がわかりやすいと思います。そして……！
Dragon A; // (Aは適当な名前です）
こう、オブジェクト指向の掟（？）に従って宣言すれば、クラスとして使えるようにできます。宣言したAを示し、Dragonクラスの関数としてプログラミングした「関数名」を加えれば、その機能を働かせられます。仮に「Bomb」という関数名をつけた処理を動かすのなら「A.Bomb( );」（※例です）。ざっくりと、こんなプログラミングをすればOKなのです。
このあと、ゲームを「1人から２人同時に遊べるようにしたい！」。ふと思ったとき、手間暇はあまり考えなくて良くできてしまいます。
Dragon A,B; //（A、Bは適当な名前）
またも掟に従って２つ宣言すれば、AとBのそれぞれ独立したDragonクラスを作れ、わずかな作業で２人プレイのゲームにグレードアップできます。便利です。
先ほどのように「Bomb」という名をつけたDragonクラスの処理（関数）を使うのならば「A.Bomb( );」や「B.Bomb( );」と指示を記すだけで、独立して動きます。データ（変数）や処理は、クラス毎に「完全に分離・独立」しているため、データなどが入り混じって不具合まみれ、とはなりません。
例外はあるものの、B.Bomb処理からA.Bomb処理へ、その逆も「手出し（アクセス：変更操作）不能」となっています。なにせ、アクセスできると入り混じってクラスの独立性が無意味ですから。
最後に、クラスとはデータや処理の「設計図」がたくさん含まれた存在です。「インスタンス」と呼ぶ、例の「掟」で設計図を実体化（オブジェクト化）、まさしく、召喚しないと「ただの設計図」なので実際に機能しません。建物の設計図に住めないのと同じです。
なら、まったく同じ処理をするクラス(設計図）が２つあっても、
意味がない？
そう考えるのは早計です。クラスには先ほど、ちらっと触れたように、別の人が作った処理・機能に「新しい機能追加をしてパワーアップ」させたり「アレンジするように変更」してみたり、「発展」や「応用利用」可能な点がウリですので。それぞれをアレンジして活かせます。
再利用（＝コピペして使いまわし）ができる「クラス持ち」（クラスの記述やファイルをたくさん保存している人）は、お手軽なプログラミングで結構すごいソフト（プログラム）を、手早く作れてしまいます。
優雅です。お金持ちと同じで、うらやましい！
いったんここで終わります。最後まで読まれて「オブジェクト指向」のスゴそうな雰囲気だけでも、掴めていただけたでしょうか？
お読みくださりありがとうござります。費用未払い「大手大型倒産」を受けて、創作活動の継続がかなり危機的です。助っ人いただけましたら幸いです。 みなさまに喜んで楽しんでいただける創出をつづけます！ 朽ち果てるまで……