オブジェクト指向でなぜ作るのか 第4章を読んだ
はじめに
このエントリーの続き。 引き続き思考の整理、アウトプットとして。
第4章 OOPは無駄を省いて整理整頓するプログラミング技術
今までの章の流れから、じゃあ実際OOPってどういう特徴があって何が嬉しいの?の部分をちょっと長めに取って説明している章。
OOPには三つの大きな要素がある
- クラス
- ポリモーフィズム
- 継承
それぞれの効能(嬉しい点)については以下
クラス
- まとめる
- 隠す
- たくさん作る
上記がクラスの効能。
- 部品が減るというメリット
- 命名が楽になるというメリット
- 部品が探しやすくなるというメリット
がある。
この辺は当たり前のようにやっているので改めて説明されて再確認という感じ。逆にクラスがなかったら、とっちらかっているという説明をしっかりとされて、偉大さを再確認できた。
また、機能をクラスにまとめているので命名も楽になるし部品が探しやすくもなる。
命名は気をつけなければいけないものではあるものの、クラス内の部品という隠された内部のことであるならばシンプルに保てるよねという話。
探しやすさについてはIDEの進化も合間ってすごく楽。
ポリモーフィズム
呼び出す側のロジックを共通化する仕組み
ポリモーフィズムについては、今まで一番言葉の定義を曖昧にしながら使ってきたものかもしれない。interfaceのようなものと理解した。
自分としてはinterface設計自体があまり得意ではなく、慣れていないので、しっかりとできるようにしたい。
その効能としては、接点を共通化することで、実装を隠蔽することができる。という風に認識している。似たような処理を一つのinterfaceとして提供することで、呼び出し側での手戻りを少なくできる。
継承
複数クラスの共通する部分を別クラス(スーパークラス)にまとめて、コードの重複を排除する仕組み。
これはよく使うから馴染みがある。
ただ、クラス設計をうまくできずに巨大なスーパークラスが出来上がってしまったこともある。
個人的には継承とポリモーフィズムを綺麗に使い分けて整頓されたコードを仕上げることをできるようになることが課題かなと思う。
これで三つの説明をまとめた。
この他に、パッケージ、例外、ガベージコレクションについても軽く触れられていたので説明する。
- パッケージ
- クラスをまとめる仕組み
- PHPで自作パッケージを使用することがなかった(それほど大規模なプロダクトじゃなかった)のでイメージはComposerでインストールするパッケージやライブラリたち
- クラスをまとめる仕組み
- 例外
- 戻り値と違う形で特別なエラーを返す仕組み
- 当たり前のように使っていたが、例外がないと全てハンドリングして返さなければいけない
- Golangをちょっとやった時に例外がなくて大変だなと苦労した
- 戻り値と違う形で特別なエラーを返す仕組み
- ガベージコレクション
- インスタンスを作った時、不要になった時点で自動でメモリを解放してくれる機能
- 意識したことがなかったが、こんなに素晴らしい機能が標準で言語に備わっているのかというお気持ち
今までの章と比べるとボリュームがあったが、いい感じにまとめられていて読みやすかった。