オブジェクト指向でプログラミングしていく時はこうした方が
良いってことがいくつかある。
1 つは オブジェクト指向 のカプセル化にあるように
変化する部分をカプセル化するってこと。基本中の基本だけど難しい…
同じくらい重要なのが、インターフェース。
インターフェースはポリモーフィズムをうまく使っている方法だね。
さて今まで 2 つのパターンを見てきたけど、具象実装に対してプログラミングしないことになるよね。
必ずインターフェースに対してプログラミングすることになる。
例えば、strategy パターン(observer パターンもそうだけど)では
コンポジション(Has-a 関係)しているよね。そこで戦略を利用する側では何に対して
プログラミングするかっていうと、作成されたインターフェースに対して
プログラミングする。具象実装には一切触らない。
こうすると依存関係が少なくなるから(具象実装に対してプログラミングしたところを想像してみる)、
具象実装の再利用、交換、追加、削除などが簡単になる。
これが実装に対してではなく、インターフェースに対してプログラミングするってこと。
これは覚える。
具象実装に対してプログラミングしたところを想像してみる
例えば、戦略を交換するときどうすればいいだろう。if 文で解決できそうだけど、
それは再利用や交換などを行なうのが容易じゃないのは明らかだし、保守性も悪そう。
具象実装に対してプログラムすると良くないってのが分かる。
良いってことがいくつかある。
1 つは オブジェクト指向 のカプセル化にあるように
変化する部分をカプセル化するってこと。基本中の基本だけど難しい…
同じくらい重要なのが、インターフェース。
インターフェースはポリモーフィズムをうまく使っている方法だね。
さて今まで 2 つのパターンを見てきたけど、具象実装に対してプログラミングしないことになるよね。
必ずインターフェースに対してプログラミングすることになる。
例えば、strategy パターン(observer パターンもそうだけど)では
コンポジション(Has-a 関係)しているよね。そこで戦略を利用する側では何に対して
プログラミングするかっていうと、作成されたインターフェースに対して
プログラミングする。具象実装には一切触らない。
こうすると依存関係が少なくなるから(具象実装に対してプログラミングしたところを想像してみる)、
具象実装の再利用、交換、追加、削除などが簡単になる。
これが実装に対してではなく、インターフェースに対してプログラミングするってこと。
これは覚える。
具象実装に対してプログラミングしたところを想像してみる
例えば、戦略を交換するときどうすればいいだろう。if 文で解決できそうだけど、
それは再利用や交換などを行なうのが容易じゃないのは明らかだし、保守性も悪そう。
具象実装に対してプログラムすると良くないってのが分かる。