【９月４週目】オブジェクト指向設計実践ガイドを読んで【２／２】

第5章 ダックタイピング

ダックタイピングとは以下のフレーズで語られることが多いかと思います。
"If it walks like a duck and quacks like a duck, it must be a duck" （もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルに違いない） この言葉を初めて目にしたとき「そんなの当たり前じゃないか」となって呆気に取られた記憶があります。
これの言葉をもっとプログラミング的に言い換えると、「オブジェクトがアヒルのように歩き、アヒルのように鳴くメソッドを実装しているなら、そのオブジェクトはアヒルであるに違いない」となります。ダックタイピングはどのようなクラスとも結びつかないインターフェイスのことをいい、クラスへの依存度を上げないというメリットがあるので、変更にかかるコストを下げることができます。

ダックタイピングを理解する

先ほどは「どのようなクラスとも紐づかないインターフェイス」ということを理解しましたが、その理解はまだふわっとしたままです。もう少し掘り下げて理解を深めます。

まとめ

さいごに、本書を通して学んだテクニック的なメモを残しておきます。※本書の引用でなく、僕なりにまとめた文章なのであしからず。

・複数の責任（処理）を持つオブジェクトは簡単に再利用できなくなってしまうため、クラスもメソッドも単一責任にするのが基本。単一責任かを確かめるには、そのクラスを一言で説明してみる（説明できたら単一責任）。

・依存は少ないに越したことはないが、ゼロにすることはできない。不必要な依存は排除し、依存は隔離（一か所にまとめる）する。

・依存を隔離する手段として、ラッパークラス・ラッパーメソッドがある。依存箇所をラッパーメソッドで包み、そのラッパーメソッドを参照するようにしてやれば、依存先のクラスの仕様が変わったとしても、依存箇所はその一か所で済む。外部オブジェクトへの依存だけでなく、インスタンス変数など様々な個所から参照されうるものは、ラッパーメソッドで包んでおけば変更に強くなる。

・AがBに依存するか、BがAに依存するか、コントロールできる場合は、変更されづらく、依存されている数が少ない方のオブジェクトに依存させる。依存方向を意識する。

・パブリックインターフェースとメッセージが、アプリケーションを構成する。シーケンス図を用いてオブジェクト間でやり取りされるメッセージを図示することで、必要なオブジェクトを洗い出すことができる。

・ダックタイピングを使いこなすことで、よりインターフェースを柔軟にでき、クラスへの依存を排除できる。ダックタイピングは具象的な存在でないため、理解しづらいという難点はある。テストコードをしっかり書いて明文化すること。他人が書いたダックタイプを破壊しないように、ダックタイピングの概念を理解しておくこと。