オブジェクト指向学び直し

software design2021年3月号を読んで

手続き型プログラミングは小さなものをシンプルに記述するときに向き、 オブジェクト指向プログラミングはより大きく複雑なものを分割して記述するときに向く

よくオブジェクト指向は大規模開発で使われる、って言われるけど、 初学者は大規模開発ってなんとなくわかるけどなんでそれを使うと嬉しいのかがちゃんとわからないと思うんだよな。 実際に現場でて、大規模システムに触れると「ああこうしてるから調査しやすいな」とか「なんでこれ密結合してんのよ」とか色々考えられるようになった。 まあ実際に開発してる時にコスト考慮した上で妥協することもあるんだけど・・・ 凡人以下の自分には机上の勉強だけじゃ全然足りなくて、現場で実物に触れてやっとわかるようになったな、って思う。

カプセル化はデータとロジックを1つのクラスにまとめる考え方

「getter/setterを作ってデータを不本意に編集されないようにする」みたいなのがカプセル化です、っていう認識だったからちょっとびっくり。忘れてくださいとまで書いてあって草。でも今なら納得。

StringクラスとLocalDateクラスを例にあげて説明してくれてた。 このクラス設計を真似するといいよ、って。カプセル化の超いい見本がこんな身近にあったとは。

手続き型のクラス設計は、データクラスと処理クラスを分ける方法なんだけど、今のPJこれなんだよな。 でも扱うデータ種類ごとにパッケージ分けてコンポーネントクラス作ってるからこれもこれで理にかなっているのか？ システムの数だけ設計が存在する、を心に。

凝集度って他の本でもみたけど、凝集度の高いクラスを作るのはオブジェクト思考の基本。 いろんなデータ型を扱う登録系の処理をまとめるクラス作るより、特定のデータのみを扱うCRUD処理をまとめたクラス作った方がいいよ、ってことだよな。

オブジェクト指向ではイミュータブルな設計が主流。イミュータブルは、不変の意。 オブジェクトを生成した後に、その中身の値は変えないような設計にすると、処理が安定するらしい。 中身の値が変わらないから、意図しない動きしないからバグ減るので。 今のPJ余裕でミュータブルな設計だな。 本では「最近はイミュータブルな設計が主流」って書いてあったから、そりゃそうか。 でもちょいちょいイミュータブルしてる（？）処理みたことあるんだよな。