オブジェクト指向とかclassとかが良くわからないので調べてみた

オブジェクト指向がよく分からないのでいろいろ調べた自分用のメモです。

１．オブジェクト指向の意味(wikipedia)

オブジェクト指向（オブジェクトしこう）とは、オブジェクト同士の相互作用として、システムの振る舞いをとらえる考え方である。英語の object-oriented (直訳は、「対象物志向の」「目的重視の」という意味の形容詞) の日本語訳である。
オブジェクト指向 – Wikipedia

わかったような、分からないような。
データ指向設計と比べてみるとなんとなく分かるような気もしますが、オブジェクト指向で何が嬉しいのかはまだ掴めないです。
そもそもオブジェクトとはなんなのでしょうか？

２．オブジェクト指向とは？

オブジェクトという単語を日本語に訳すとするとカタカナ表記の”モノ”がフィーリング的には一番近いでしょうか。
クラスも関数も構造体も、プログラミングの世界では全てオブジェクトという扱いになるみたいです。
ただ、このオブジェクトという言葉で分かりにくいのは、設計図であるクラスも実体であるインスタンスも、全部が全部オブジェクトという扱いになってしまうと言うところでしょうか。

このことを踏まえると、オブジェクト指向の「オブジェクト同士の繋がりに重点をおく」と言う考え方も若干しっくりくるような気もします。

手続き型プログラミングが処理の順番をベースにプログラムを考えると言う点と対比させると、オブジェクト指向プログラミングは処理を行うモノをベースにプログラムを考えると言うことなのでしょう。

３．オブジェクト指向で何が嬉しいのか？

とりあえずオブジェクト指向がなんぞや、と言うことは掴めた気がします。
でもオブジェクト指向にすると何が嬉しいのでしょうか？
一般的には、再利用性が高まってコード量が減るとか、保守性が高まるとか言われていますね。

４．オブジェクト指向の３大要素

一般的に言われているオブジェクト指向の３要素には以下の三つがあります。
①カプセル化：内部の処理を外に漏らさない
②継承：ある機能を元に別の機能を作ることができる
③ポリモーフィズム：状況によって動作を変えることができる

①はオブジェクト指向は関係ないですね。
カプセル化はプログラミング共通のルール的な側面がありますし。

②は共通化という考え方になるのでしょうか。
確かに共通の何かを作っておいてそれを再利用するようにしておけばコード量を減らすことはできそうですね。
ですが、共通部分に変更が入った時に悲劇がおきそうです。
事前の設計が大事なんでしょうね。

③は関数の引数が変わるみたいなものじゃないんですかね。なんか特別な意味があるのでしょうか？？

オブジェクト指向の５原則(SOLID原則)

SOLID原則と呼ばれるオブジェクト指向設計の５原則は以下の原則からなります。

①SRP(単一責任の原則)
・一つのオブジェクトには一つの責任しか持たせててはいけません。

→データ管理クラスを作ってDBとファイルの両方を管理させるのはダメってことですね。でも、DB管理クラスとファイル管理クラスを作って、それをラップするデータ管理クラスを作るのはありなんでしょうか…？

②OCP(オープン・クローズドの原則)
・修正に対して閉じ、拡張に対しては開いていなければいけません。

→クラスに何か追加する場合に既存部分に手が入らないように追加できるような設計になっていないとダメってことですね。

③LSP(リスコフの置換原則)
・サブクラスはスーパークラスで置換可能でなければなりません。

→確かに使う側からしたらスーパークラス使えるならサブクラスも使えると思いたいですよね。サブクラスはスーパークラスよりも引数の条件が緩く、戻り値の条件が厳しければ置換可能と言えるらしいです。

④ISP(インタフェース分離の原則)
・インターフェイスは使い方にあった細粒度の単位で作成しなければなりません。

→使わない実装に依存するのは避けましょうってことですね。

⑤DIP(依存関係逆転の原則)
・依存関係はインターフェイスにもたせましょう。

→外側とやりとりするルールさえ決めておけば内部実装の変更には柔軟だぜ、的なイメージですかね。APIとかOSI参照モデルみたいですね。

オブジェクト指向に出てくるクラスとは？

イメージ的には変数(プロパティ)+関数(メソッド)？
で、ポイントなのがclassはただの設計図みたいなもので実体(いわゆるインスタンス)は別途用意してあげないといけないってことでしょうか。
classを宣言しただけだと、型宣言しただけの状態みたいってことかしら。

classを用意したら何がうれしいのか？

オブジェクト指向で何が嬉しいのか、と同じ感じですが。

①使いまわしやすい
classは設計図でその実体を用意することができるので、classを元に実体をいっぱい作れるということですかね。
ゲーム作るときにキャラクタークラスを作っておけばその実体をばんばん作れるってことですよね。
これだけだったら構造体を配列で用意するのと大して変わらない気もするのですが、後述の継承とか多様性が使いまわしやすさに効いてくるんでしょう。

②プログラムの保守性が高い
自分は独りで作ってメンテしてることが多いんで、この恩恵はイマイチわからないのですが、classの中では、privateな変数(or 関数)とpublicな変数(or 関数)ってやつがいるらしく、privateな変数はそのclassの中からしかアクセスされないんだそうです。
だから、「変更しても大丈夫なデータと使ってもいい関数だけpublicにしておけば大人数でプログラミングする時も安全！！」らしいです。
APIみたいって思ったけど、誰かがclass書き換えたら結局安全ではないですよねと思ってしまう今日この頃。