オブジェクト指向を思想のように捉えることは混乱を生みます。エレガントな手段！なんてものではなく、タイトルの通り、それなりの規模のプログラミングに対する妥当で、現実的な手段ではないのでしょうか。オブジェクト指向の本質を理解した気がするので、考えをまとめたいと思います！
むしろ補助的な機能
オブジェクト指向に振り回されがちな初心者プログラマですが、自分も最初は掴み所がなくて困惑しました。クラスは設計図のようなもの・・・ようなものってなんだよ！？みたいな。
Unityでやることを含め、最初の言語としてC#を選択する人が少くないと思いますが、C#はオブジェクト指向の言語です。そのためオブジェクト志向な考え方にどっぷり浸かることになります。
つまり、オブジェクト指向がプログラミングにおける本分のように錯覚してしまうわけですね、自分も最初そう思いましたし、同時に初歩的なこととオブジェクト指向的なもののが噛み合ってこないので、そこで要領を掴めなかったりもしました。それもそのはずで、オブジェクト指向はむしろ補助的な機能に他ならないわけで、実は初心者はそれほど気にすべき事柄ではないのです。
コーディングにおける二つの目的とは？
プログラミングには、いろんな機能やテクニックがありますが、それらは主に二つの目的のために存在していると思われます。つまり・・・
可読性、保守のための分割 コードを読む量を減らすための縮小、の二つです。
例えば、関数やメソッドというのはこの２つが組み合わさったもの、と説明できます。複数行の処理を関数化することで、他のコードと切り離し、区別できるようにし、読みやすくします。また、その処理が繰り返し使われる場合、関数を呼び出せばよくなるので、総合的なコードの量は減ります。関数の再利用というものですね！
For文なども繰り返し処理を効率的に書き表すためのテクニックですし、縮小のための道具と言えそうです。
クラスも単なる道具である。
というわけで、クラスもこの分割と縮小のための道具に他なりません。オブジェクト指向は現実世界に近い形でコードを書けるエレガントな方法だー！みたいなのは結果的にそう解釈できるに過ぎず、本来の目的は大きなプログラムを分割して、読みやすく扱いやすくし、また大きくなりすぎないようにするためのものなはずです。
カプセル化とはコードを意味のある塊にまとめる、ということであり、機能や分野ごとにまとめるというのはその方がわかりやすいから、ということになります。
難しく考える必要はなく、ただ単に分けて管理しよう、別々に考えよう、というものに過ぎないはずで、言葉遊びに付き合う必要はありません。
継承、ポリモーフィズムはコードの量を減らすためのものです。継承は関連あるクラスの重複部をひとまとめにするためのもの、ポリモーフィズムは各クラスをひとまとめにし、いろんな動作を共通のメソッドで表現し、やはりコードを少なく、簡潔にするためのテクニックです。
自分でデータ・タイプを作るための器
分割と縮小はトラブル回避のための消極的な目的ではありますが、積極的にクラスを使う目的もあります。それはデータ・タイプを自分で作れるということです。
データ・タイプとは、いわゆるInt, float, char, bool などのデータの形式や種類を表すものですが、基本的なタイプは単純なデータであり、そのデータしか扱えません。
世の中にある様々なモノは複雑な構造、概念によって形成されており、そうした単純なタイプでは表現不可能です。正確に言えば、多くの単純なタイプが組み合わさって、初めて高度て複雑な表現ができます。
要するにクラスとは、そうした数多くのデータタイプをひとまとめにし、抽象化するための入れ物になるわけです。抽象化とは、細かい事柄をざっくりと捉えることで、高度な理解、表現をするための手段です。
コンピュータ上にあるものは全てデータです。複雑で抽象的なものをデータとして定義するのが、クラス設計になります。つまり、そうした高度な概念のためにあるデータタイプを定義するためにクラスは存在します。
また、クラスはメソッドも含めることができるので、振る舞いも表すことができ、クラスから作られるモノ（インスタンス）に主体性を与えることができます。これはクラスによる分業の面から見て、とても重要です。
これにより複雑な構造を持つ、人間を含めた生き物などをコンピュータ上でデータとして、扱えるようになる、ということになります。
つまり、高度で複雑なデータを表すタイプを自分で定義できるということです。
連携という、ネック
分けた、ということはバラバラになったコード群が一つの仕事を成し遂げるためには連携しなければいけません。どう連携するかの管理のためのアイデアがアクセス修飾子です。つまり、公開、非公開にすることでクラス間の連携を制限するというものです。
連携はむしろクラスを利用するために支払わなければならないコストのようになります。なぜなら、上手く連携をするような構造になっていないと、かえってコードが複雑になってしまうからです。
プログラミング言語が人間のためのものなのに、読みにくくなってしまうのと同じように、クラス分けのせいで、プログラム全体の構造が複雑になって、把握しにくくなるのは本末転倒です。
しかし、クラス設計とは単純なコーディング以上に、物事の本質を見極める能力が求められ、難しいわけです。
ここらへんがオブジェクト指向が必要以上に叩かれる原因なのではないでしょうか。しかし、オブジェクト指向は単なる方法論であり、使わなければならないなら慎重に使わざるを得ず、他にいい方法があるなら、その方法を使えばいいだけです。
まとめ
というわけで、クラスは分割や縮小、連携、そして、自分でデータ・タイプを定義するためのもの、という説明を書いてみました。少し、長くなりましたが、かなり分かりやすく書けたかと思います。自分で言うのもなんですが。
ポリモーフィズムに関しては、Unity上の実践含めて、また改めて記事を書きたいと思います。画面中の敵を全部・・・みたいな内容です！
