オブジェクト指向を学ぶ姉妹 2章
単一責任のクラスを設計する
妹「オブジェクト指向で重要なものはメッセージってことを主張してたね～」
姉『どうしてもクラスに目がいくけど、肝はそこじゃないんだねぇ』
妹「最初の肝は、シンプルであれと主張すること、だったね！」
姉『具体的には？』
妹「いますぐに求められる動作を行ない、あとにも簡単に変更できるようにモデル化すること！」
姉『言うは秋元康くん』
妹「それをできるようにテクニックを学んでいくんだよ～」
TRUE
姉『設計とは、アプリケーションの可変性を保つために技巧を凝らすことだって』
妹「完璧を目指すための行為ではないって書いてあるね～」
姉『言い方変えてるだけでほんと同じこと何度も言ってるね』
妹「コードは次の性質が伴うべきって～」
- 見通しが良い（Transparent）
- 変更するコードにおいても、そのコードに依存する別の場所のコードも変更がもたらす影響が明白である
- 合理的（Reasonable）
- どんな変更であっても、かかるコストは変更がもたらす利益にふさわしい
- 利用性が高い（Usable）
- 新しい環境、予期していなかった環境でも再利用できる
- 模範的（Exemplary）
- コードに変更を加える人が、上記の品質を自然と保つようなコードになっている
妹「見通しが良く、合理的で、利用性が高く、模範的。略してTRUE」
姉『急にアイドルっぽい命名！』
妹「絶対に男性4人組グループ！」
単一責任かを見極める
姉『どお？妹子ちゃん。写経できた？』
妹「うん～Dartで書けたよ！お姉ちゃんは書けた？」
姉『Pythonで書いたよ！』
妹「クラスが単一責任かどうかを見極めるコツが２つ書いてあったね～」
姉『１つめはクラスを擬人化して問いただすだったね！超得意！』
妹「擬人化とは書いてないけど実質同じ意味だね～」
姉『妹クラスに、妹ちゃんの好きなもの教えて！で通じるのはいいけど、』
姉『お姉ちゃんの好きなもの教えて！が通じるのは何かおかしいってことだねぇ』
妹「それだと私がおねえちゃんの好物まで管理しちゃってるもんね～」
姉『私はウェルカムだよ！』
妹「２つめは1文でクラスを説明してみることだったね～」
姉『上の例だと、妹クラスは妹を管理する？』
妹「うーん、それだと広すぎない？複数責任負ってそう」
姉『妹クラスは妹の好きなものを管理する！』
妹「だとするとクラス名と内容が一致してないね～」
姉『妹の好きなものクラス……？』
妹「その場合まず好きなものクラスを作って、妹クラスが継承するのかな～」
姉『なるほどなー！こうやって設計を見直していくんだねぇ』
妹「こういった責任の度合のことを、凝縮度って言うんだって～」
アクセサメソッド
姉『アクセサメソッドって初めて聞いた』
妹「GetterとかSetterって聞くと、あ～あれね～ってなるね」
姉『おまじないとしか思ってなかったー。結局どんな意味あるの？』
妹「メソッドで包むことで、どこからでもアクセスできるデータじゃなくなるみたい」
姉『それって不便になるってこと？』
妹「勝手に変更されたり変な使い方される恐れがなくなるってことだよ～！」
姉『まだピンとこないなぁ』
妹「あと1ヵ所で振る舞いを定義するから、大きな変更があっても吸収しやすいの」
姉『わかりづらいいい！』
妹「鬼データを無惨様メソッドで包むことで、無惨様をいじればすべての鬼が修正されるの」
姉『わかりやすい！！！』
妹「rubyだとattr_readerを使うことで簡単にラッパーメソッドが作れるから、必ず使おうだって～」
姉『じゃあPythonでもやったほうがいいのかなー。修正してくる！』
妹「それがね～どーもPythonでは推奨されたやりかたじゃないみたいなの。」
姉『えぇぇぇ』
妹「Pythonでは言語仕様上、完全に隠匿することができないとかなんとか。」
姉『Dartは？』
妹「Dartも不必要なgetter/setterを作らないんだってー。ここらへん理由も調べとくね」
姉『言語によって方針がだいぶちがうんだねぇ』
妹「それが面白いところだよね～」
姉『最強の言語が天下統一果たすのを願うばかりだよぅ』
～続く～
