オブジェクト指向設計実践ガイド 第3章
読み進めるうちにしばしば「あのプロダクトのあの実装はこういう意図だったのでは!」と気づいて、その瞬間が気持ち良い。
第3章では特に「他クラスへのあるメッセージ送信についての依存を、そのメッセージに応答できるダックタイプへの依存に変えるとき、それはインタフェースを定義している」という趣旨の文に唸らされた。
3章 依存関係を管理する
- オブジェクトが現実世界の問題の特徴を反映し、オブジェクト間の相互作用が解決策を用意する
3.1 依存関係を理解する
- テストはコードを参照するがゆえに、コードに依存する
- テストに慣れないうちはコードと過度に依存したテストを書きがち
3.2 疎結合なコードを書く
- 依存オブジェクトの注入によるコード整形は、クラス名やそのクラスに送るメソッド名を知っておく責任が他のクラスにあるのでは、と疑える能力に左右される
- コントロールできない外部のクラス名に対する依存をどのように管理するかはアプリケーションに多大な影響を及ぼす
- 複雑なメソッドはそうでないメソッドよりも変更が必要になる可能性が高い
- 引数が必要なメッセージを送るとき、送り手は引数についての知識を持たざるをえない
- 真偽値を引数にとったり引数の false と nil を区別したいときは
||
でなくfetch
を使うのが良い - 自身のアプリケーション内のクラスは自身のアプリケーションが所有するコードのみに依存するべき
- 他クラスのインスタンス作成のみを目的とするクラスをオブジェクト指向設計ではファクトリーと呼ぶ
3.3 依存方向の管理
- 各クラスの依存は自分より変更されないクラスへの依存となるように管理する
- 依存する他クラスへのメッセージに応答できるダックタイプを定義する ≒ インタフェースの定義
- 抽象化されたものへの依存は具象的なものへの依存よりも常に安全
3.4 まとめ
- 依存関係の管理において鍵となるのはその方向を制御すること
"オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方" を読み始めた
2度目のパーフェクト PHP の読了を果たした一昨日から、オブジェクト指向設計実践ガイドを読み始めた。
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz,?山泰基
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: 大型本
- この商品を含むブログ (1件) を見る
RubyKaigi の頃あたりに 訳しました:「オブジェクト指向設計実践ガイド」 - Misoca開発ブログ のエントリを読んで気になりつつ終ぞ今日まで読むには至っていなかったのだけど、同僚の @kymmt90 が読んでいていい感じとのことだったので読み始めた。まだ2章までしか読めてないけれど、既に面白い。
もうしばらくすると仕事でガッツリ Ruby を書くことになりそうなので、そのためのリハビリも兼ねている。
今年はオブジェクト指向設計やデザインパターンといった、将来つらくならない開発するための体系的な知識を付けたい気持ちがある。
理解を深めるためにも、メモを付けつつ読んでいこうと思う。
第1章 オブジェクト指向設計
- オブジェクト指向設計の失敗はコーディングテクニックでなく視点の置き方にある
1.1 設計の賞賛
- オブジェクト指向とは依存関係を管理すること
- 知識を持ちすぎたオブジェクトは制約が増えテスタビリティが下がるだけでなく、複製もされやすくなる
- 実用的な設計は未来を予測・選択するのではなく、あとにでも設計ができるよう変更コストを下げる
1.2 設計の道具
- 設計における道具は「原則」と「パターン」
1.3 設計の行為
1.4 オブジェクト指向プログラミングのかんたんな導入
- 手続き型言語:データと振る舞いが完全に独立している
- オブジェクト指向言語:振る舞いを持つオブジェクトがデータをカプセル化する
1.5 まとめ
- 実践は常に理論より物事を知っている
- 実践とは配られたカードの中でベストを尽くすことの積み重ね
第2章 単一責任のクラスを設計する
- オブジェクト指向設計のシステムの基礎は「メッセージ」
2.1 クラスに属するものを決める
- 設計はアプリケーションの可変性を保つために技巧を凝らすことであり完璧を目指す行為ではない
- 変更しやすいコード ... "TRUE" なコード
- Transparent: 見通しが良い
- Reasonable: 合理的
- Usable: 利用性が高い
- Examplary: 模範的
2.2 単一の責任を持つクラスをつくる
- 短絡的な再利用はクラスの目的を曖昧にし責任を増やす
- 単一責任の原則は「クラスがすることは全てそのクラスの目的に強く関連すること」を求める
- 何もしないことによる将来的なコストが今と変わらなければ設計の決定を延期する
- 決定は必要なときにのみ、その時点で持っている情報を使って行う
2.3 変更を歓迎するコードを書く
- インスタンス変数は大抵の場合アクセサメソッド等によってオブジェクトとして扱えるようにするのがよい
- メソッドもクラス同様に単一の責任をもつべき
- メソッドを単一責任にするためのリファクタリングは最終的な設計が見えない状況でもするべき
- 隠蔽されていたクラスの目的が明らかになる
- メソッドにコメントする必要がなくなる
- アプリケーションにとって健康的なコードの書き方(再利用)を促進する
- メソッドの移植性が高まる
2.4 ついに、実際のWheelの完成
2.5 まとめ
2016 -> 2017
あけましておめでとうございます。今年もよろしくお願いします。
去年の感想やまとめと今年の気持ちエントリです。
2016 と 2017
2015年の7月まで8ヶ月ほど休職し、フルタイムの仕事に戻ったのは去年の2月で、2016年はリハビリ期間という感じだった。
一時は本当に社会復帰できるのか、アルバイト生活になるのでは等々考えていたものの、多くの人に助けてもらいなんとか復帰することができた。感謝しております。
復帰後は後輩の開発サポートから始まり、大きめな機能開発を担当したりWEB+DBへの寄稿機会をいただけたり4万人以上が使うアプリケーションの稼働言語のバージョンアップを単独で任せてもらったり(これはまだ終わってない)と、それなりに立ち回ることができた。
またメンタリティについて、"自分がどうなりたいか" を基準に行動選択できるようになってきたのは大きな変化だったと思う。これまでは周囲の凄く見える人達を見ては無闇に自分と比較し、自身の成果を蔑んで自己肯定感を失いがちだった。
一方で睡眠障害との付き合いはずっと変わらず頭を痛めているところ。
これについては、その日の体調に合わせて出社時間や勤務時間を調整できればストレスを減らせ、余計な悩みで学習が阻害されることも減り、パフォーマンス上昇最高じゃん、という見解があるので2017年中に何らかの方法でフレックスや裁量労働の勤務形態で働ける状態にしようと思っている。
睡眠障害の云々を除いても、多少出社時間がズレても進捗に影響しない業務にあたっている中で、市役所や病院に行くために給与を削って遅刻したり有給を取得したりすることに馬鹿らしさを感じていることも理由にある。
それも含め、2017年は身辺の変化が色々起こる見込みだけど、2016年にできた成長を大きく上回って成長したいと強く思っている。
テーマは「できないことはやらない」と「結婚しても困らない年収にする」の二本立て、やっていくぞ!!!
読書
読了したものが31冊、途中まで読んだものが15冊くらい。読了したものの過半数が漫画。全然読めてないなと思う。
技術書は途中で移ろいがちだった。移ろうことが必ずしも悪いとは思わないけど、1分野くらいはどしっと腰を据えて深い知識を付けるべきだったように思う。結構な頻度で移ろってしまった。
今 PHP とデザインパターンの学習を進めているので、ひとまずこれを集中・継続していこうと思う。成功体験を得たい。
日本酒
お店や人の家で飲んだものは記録漏れが多くあるので自宅で飲んだものに絞ってリスト。
- 風が吹く グリーンラベル
- 天明 零号中取り
- 百春 美濃囲い
- 幻舞 中取り純米
- 奥 十年古酒
- 澤屋まつもと 守破離
- 三芳菊 袋しぼり純米大吟醸
- 奈良萬 酒未来 純米吟醸
- あづまみね 美山錦 純米吟醸
- 花陽浴 山田錦 純米大吟醸
- 雪鶴 袋しぼり純米吟醸
- 東洋美人 ジパング
- 浦霞 純米吟醸 浦霞禅
- 十六代九郎右衛門 金紋錦
- 櫛羅 純米吟醸
- 一博 純米吟醸
- 風の森 雄町 笊籬採り
- 獺祭 磨き3割9分
- 霧降 山田錦 純米大吟醸 斗瓶囲い
- 越の白雁 彌彦愛国
- 寶剣 酒未来 純米吟醸
- 結人 本生 純米大吟醸 うすにごり
- 王祿 渓 直汲み
- 天青 千峰 酒未来 純米吟醸
- ゆきの美人 純米大吟醸 18年古酒
- 死神 裏ラベル
- 刈穂 秋 kawasemi
- 百十郎 白炎
思ったより飲んでなかった。
今年始めて飲んだ銘柄では特に風が吹くや百春、死神が美味しかった。別の造りのものも飲んでみたい。
その他では花陽浴や王祿は安心の美味しさで最高だった。あと奈良萬の酒未来には1升3000円弱でここまで美味しいお酒があるのかと驚かされたことを覚えている。
余談だけど2016年は恐らく10回以上飲んだあと記憶を飛ばしたので、2017年は飲み方を改めたいと思っている。