ravelll の日記

よしなに

オブジェクト指向設計実践ガイド 第3章

読み進めるうちにしばしば「あのプロダクトのあの実装はこういう意図だったのでは!」と気づいて、その瞬間が気持ち良い。

第3章では特に「他クラスへのあるメッセージ送信についての依存を、そのメッセージに応答できるダックタイプへの依存に変えるとき、それはインタフェースを定義している」という趣旨の文に唸らされた。

3章 依存関係を管理する

  • オブジェクトが現実世界の問題の特徴を反映し、オブジェクト間の相互作用が解決策を用意する

3.1 依存関係を理解する

  • テストはコードを参照するがゆえに、コードに依存する
    • テストに慣れないうちはコードと過度に依存したテストを書きがち

3.2 疎結合なコードを書く

  • 依存オブジェクトの注入によるコード整形は、クラス名やそのクラスに送るメソッド名を知っておく責任が他のクラスにあるのでは、と疑える能力に左右される
  • コントロールできない外部のクラス名に対する依存をどのように管理するかはアプリケーションに多大な影響を及ぼす
  • 複雑なメソッドはそうでないメソッドよりも変更が必要になる可能性が高い
  • 引数が必要なメッセージを送るとき、送り手は引数についての知識を持たざるをえない
  • 真偽値を引数にとったり引数の false と nil を区別したいときは || でなく fetch を使うのが良い
  • 自身のアプリケーション内のクラスは自身のアプリケーションが所有するコードのみに依存するべき
  • 他クラスのインスタンス作成のみを目的とするクラスをオブジェクト指向設計ではファクトリーと呼ぶ

3.3 依存方向の管理

  • 各クラスの依存は自分より変更されないクラスへの依存となるように管理する
  • 依存する他クラスへのメッセージに応答できるダックタイプを定義する ≒ インタフェースの定義
  • 抽象化されたものへの依存は具象的なものへの依存よりも常に安全

3.4 まとめ

  • 依存関係の管理において鍵となるのはその方向を制御すること

"オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方" を読み始めた

2度目のパーフェクト PHP の読了を果たした一昨日から、オブジェクト指向設計実践ガイドを読み始めた。

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デザインパターンの学習を進めているので、ひとまずこれを集中・継続していこうと思う。成功体験を得たい。

日本酒

お店や人の家で飲んだものは記録漏れが多くあるので自宅で飲んだものに絞ってリスト。

思ったより飲んでなかった。

今年始めて飲んだ銘柄では特に風が吹くや百春、死神が美味しかった。別の造りのものも飲んでみたい。

その他では花陽浴や王祿は安心の美味しさで最高だった。あと奈良萬の酒未来には1升3000円弱でここまで美味しいお酒があるのかと驚かされたことを覚えている。

余談だけど2016年は恐らく10回以上飲んだあと記憶を飛ばしたので、2017年は飲み方を改めたいと思っている。