前置き
この記事はオブジェクト指向設計実践ガイドを読んだ個人の感想メモです。
内容については、自分で考えた具体的な例を交えて書いてあります。内容に勘違いがありましたら、そっと教えていただけますと嬉しいです。
オブジェクト指向設計実践ガイド4章「柔軟なインターフェースを作る」
オブジェクトは「何を望むのか」をメッセージとして伝えるべきであって、「どうやるのか」を知っておく必要はない。
（例）
たとえば、CustomerがBicycleをレンタルしたいとする。
このときに、CustomerはBicycleを用意してくれる、Mechanic(整備士)に何を伝えるべきだろうか？
もし、CustomerがBicycleについて詳しい場合
- 「ちゃんとパンクしてないか確認して！」
- 「ブレーキがちゃんと効くか確認して！」
- 「サドルがちゃんと固定されているか確認して！」 …
のように「どうやるのか」の具体的なメッセージをMechanicに送ることになる。
確かにこれで、Bicycleはレンタルできるかもしれないが、これには致命的な問題がある。
それはCustomerはレンタルできるBicycleの条件を常に知っていなければならないということ。
もし今後、Carもほしい、Airplainもほしい、、、となったときに、Customerはそれぞれのレンタルできる具体的なメッセージを持ち続けることになる。
極端な例だが、Bicycleに夜間のための反射板をつけていないことが違法になったとする。
このときCustomerはそのことを知らなかったが故に、警察に捕まってしまった、という事態になり兼ねない。
ではCustomerはどうすればよかったのか。
常にBicycle、Car、Airplainのレンタル条件について知り続ける？
ここで初めて「delegate(委譲)」という概念が生まれる。
そして、冒頭の「何を望むのか」をメッセージとして伝えるべきであって、「どうやるのか」を知っておく必要はない。」が繋がってくる。
つまり、CustomerはMechanicに対して「いい感じのBicycle用意してよ」と丸投げする。
CustomerはMechanicが”いい感じの”Bicycleを用意してくれると期待している。
当然、CustomerはMechanicがタイヤの圧を確認しているのか、とか、反射板のテストをしているか、とか知っていない。
これにより、CustomerはCar、Airplainに関してもそれぞれ「いい感じに用意してよ」という「何を望むか」のメッセージを送るだけで済むようになった。
もちろん、「いい感じ」はCustomerによって異なるので、レンタルしたい日時や予算感を教える（メソッドに引数を渡す）ことが必要になってくる。
（現実の仕事でも、予算感も締め切りも言わずに、いい感じにしておいてーってのはヤバイ仕事とかだと意外とよくある話かも...w）
というお話。
まとめ
抽象化すると、
Mechanicに対して「どんなメッセージを送ればいいのか」 = 「Mechanicとのインターフェースは何が適切か」ということを考えることが大切であるということ。
本では「お客がレストランでメニューを見て注文して、出てきた料理を食べる」という事象に対して、「レストランでお客がレストランでメニューをみて注文したと思ったら、厨房に入ってきてスープを作り始めた」ってどう考えてもおかしいよねwっていう話が書いてあってめっちゃ納得した。