『オブジェクト指向設計実践ガイド』
https://images-na.ssl-images-amazon.com/images/I/51-TCt0H4UL._SX379_BO1,204,203,200_.jpg
読もうと思った動機
業務でPHPを書く必要が出てきたが、そういえばなんちゃってOOPしか知らんなと思って買った
ちゃんと調べてないが評判が良いっぽいのでこれにした
OOPの応用というよりは基礎的な部分をちゃんと理解したい
責務とはなにかとか、良い抽象化、良いインターフェースとはなんぞやを知りたい
mrsekut.iconはfunctional-orientedの方が好きなので、それと対比させるためにもちゃんと知っておきたい
特に1~4章を読みたい
各章が完全な独立ではなく前章の内容を引き継いでいるので飛ばして読みづらい
この本って、「OOPの最初の一歩」みたいな本なので、これ読んで十分と思っていると痛い目見る気がするmrsekut.icon
少なくともこの本の知識だけでは良いモデリングはできないと思う
第1章 オブジェクト指向設計
設計は芸術。コード構成の芸術。
未来に変更が加わることを想定する、認める
具体的に何が起こるのかを予測しろとは言っていない
第2章 単一責任のクラスを設計する
https://gyazo.com/f7c7dc973df8db3d1c2875e77df8c5d5
Object (class)に目が行きがちだが。
アプリケーションの可変性を保つために技巧を凝らすこと
カンペキを目指すための行為ではない
Transparent
Reasonable
Usable
Exemplary
単一責任なmethodの利点として挙げられている「他のクラスへの移動がかんたん」は純粋関数であることが必要条件にあるように思うmrsekut.icon
「まだまし」という意味で言っているならそらそう
第3章 依存関係を管理する
tsで書きながら見てみる
せっかくなのでPHPにするか..
CBO
Object間の結合
Wheelの依存を外した
脆い外部メッセージを隔離する
へー、これもだめなんだmrsekut.icon
外部メッセージを専用methodにカプセル化する
これをしなかったときの問題を考えたい
この文脈上で
これに関してはあまり必要性を感じない
何が改善されたのかいまいちわからん
第4章 柔軟なインターフェースをつくる
p.89の下から2段落目の「そのほかのインターフェース」の方が何を指しているのかわからん #?? 5章で話すとのことなので理解を保留しているmrsekut.icon
シーケンス図の読み方わからんのでこのサンプルコードが理解の助けになったmrsekut.icon p.100らへんのTripとMechanicの知識の話
こういう流れで話されると確かに自然に見えるが、
Tripの利用者が、「自転車を洗浄したい」という要望を出すことはないのか
ないのか、というかあった場合どうすればいいのか
Tripが「準備の詳細について知りすぎている」ことが問題なのではなく、Tripに要請される振る舞いと言うか、Tripの利用者目線で考えるわけではないのか？
Tripの利用者が本当に「準備する」という振る舞いだけで満足するなら、p.100の修正は自然だとは思う
「howじゃなくwhat」の説明だった。じゃあまあいいか。そういう例なんだろう
p.101~のコンテキストの話
問題はわかる
修正例が、その修正によってどう改善されたのかピンときていないmrsekut.icon
DIされてよかったね、というのはわかる
再読しようmrsekut.icon*2
コンテキストの話ってシーケンス図(だけ)から読み取るのちょっと難しくない #?? これを議論する場としてシーケンス図は適当なのか？
単にmrsekut.iconが慣れていないせい、というのもある
Mechanicが知っていることが増えたけどこれはいいのか
ここ以前の修正は自分にもできる気がするが、このコンテキスト部分の修正はできる気がしないな..
まだなにか見えていない気がする
OOP、暗黙的な守るべきルール多すぎやろ..mrsekut.icon
第5章 ダックタイピングでコストを削減する
最後の方の節はアンチ静的型付けの話だった
第6章 継承によって振る舞いを獲得する
舗装されていない荒い道を走る用
頑丈なフレーム
太いタイヤ
真っ直ぐなハンドル
サスペンション
ハンドルバーにテープがある
https://gyazo.com/0dc5182ffc37d446f192d9c6524a10a6
この赤いやつのことかmrsekut.icon
既存のBycycleと呼んでたclassが、ロードバイクを表している
後にマウンテンバイクが追加されたので命名が歪になっている
これはp.153あたりで指摘され修正される
めっちゃ逐次的な変更で話が進んでいく
途中で読む期間あけるとわからなくなりそうmrsekut.icon
抽象から具象を取り出すのは難しい pp.159-160
ミスった時に問題が生じる
しかし、逆に具象から抽象を切り出すのは簡単
ミスったとしても大きな問題は起こらない
言っていることはわかるmrsekut.icon
class特有の考え方な気がするので、知見としてはあまり汎用性はなさそう
どちらの方向にしても移動させるものの選択を謝れば意味ないが
サブクラスに分けるための判断軸が、「共通部分であるかどうか」にあるの、なんとも言えないなmrsekut.icon
マウンテンバイクとロードバイクの共通部分が、既に自転車としての責務を超え出ている可能性がある
p.162辺りで軽く言及されていた、流石にそうだよねmrsekut.icon
フックメッセージというテクニックは、言語に依って強制されるわけでもなく「実装者が知識として知っているか」に依存するので、やはりOOPは難しいmrsekut.icon
第 7 章 モジュールでロールの振る舞いを共有する
Rubyのmoduleや、PHPのtraitらへんの話
継承とtraitを使うようになるとめちゃくちゃ複雑になる
そこで呼ぶメッセージは以下の4パターンがアリうる
自分自身に実装されているmethod
自分の親class(の親class(の..))に実装されているmethod
自分が利用しているtraitのいずれか内で実装されているmethod
自分の親class(の親class(の..))が利用しているtraitのいずれか内で実装されているmethod
メソッド探索の仕組み
ロールの振る舞いを継承する
7.2 継承可能なコードを書く
アンチパターン
抽象に固執する
契約を守る
テンプレートメソッドパターンを使う
前もって疎結合にする
階層構造は浅くする
7.3 まとめ
8.1 自転車をパーツからコンポーズする
ByscleとPartsの違いがよくわからん #?? Partsはただの部品の集合であるだけで、自転車としての機能は持っていないのか
いまのところ、Parts ClassをRoadBikeParsやMountainBikePartsが継承している
Bycycle側でもParts側でも継承が起きている
いまのところPartsに全てを移動しただけなので継続と対して差はない
どでかいやつを置く場所を移動しただけ
もっと小さい部品に分けないと小回りがきかない
8.2 Partsオブジェクトをコンポーズする
このPartsとPartの関係みたいに、コンポジションやるときは常に、複数形-単数形の関係のclassが必要になるのか #?? 個々のパーツ(タイヤとかチェーンとか)を、Part classのinstanceとして作る
実際はPart classのinstanceだが、コンポジション的にはそう捉えないらしい
Partのロールを持った個々のオブジェクトです。と捉える でも、実際instanceだから、引数で与えられた以上の働きはできなくない #?? chain固有、tire固有のmethodとかは作れないじゃん
8.3 Partsを製造する
PartsFactoryによって、Part classが不要になる
個々のPartは共通のInterfaceを持っていないといけないの？
8.5 コンポジションと継承の選択
継承による影響を認める
コンポジションの影響を認める
関係の選択
8.6 まとめ
第9章 費用対効果の高いテストを設計する
9.2 受信メッセージをテストする
DIの良さみたいな話をしている
当たり前すぎることを言っているからか、冗長だからかわからんがあんまり頭に入ってこないmrsekut.icon
プライベートメソッドは決して書かないこと。書くとすれば、絶対にそれらのテストをしないこと。ただし、当然のことながら、そうすることに意味がある場合を除く
クラスを使って依存オブジェクトを注入する
ロールとして依存オブジェクトを注入する
9.3 プライベートメソッドをテストする
テスト中ではプライベートメソッドを無視する
テスト対象クラスからプライベートメソッドを取り除く
プライベートメソッドのテストをするという選択
9.4 送信メッセージをテストする
クエリメッセージを無視する
コマンドメッセージを証明する
9.5 ダックタイプをテストする
ロールをテストする
ロールテストを使ったダブルのバリデーション
9.6 継承されたコードをテストする
継承されたインターフェースを規定する
サブクラスの責任を規定する
固有の振る舞いをテストする
9.7 まとめ