Locked History Actions

Diff for "Designs/DIP"

Differences between revisions 4 and 5
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
反論2からもわかるように、著者の想定はそもそも古すぎるのである。どういうわけか、この章で著者は、'''20年以上も前の古めかしいソフトウェア設計を前提にしている'''のである。P16、わざわざ耳慣れないレイヤー「Policy Layer」「Mechanism Layer」「Utility Layer」を出しているのはそのためである 反論2からもわかるように、著者の想定はそもそも古すぎるのである。どういうわけか、この章で著者は、'''20年以上も前の古めかしいソフトウェア設計を前提にしている'''のである。著者はP16主張している。「事実、従来手法の目標の一つは、上位モジュールから下位モジュールの呼び出し方を定義したプログラムの階層構造を作ることなのだ」。現代のソフトウェアではそうとはいえない
Line 37: Line 37:
上にあげた近代的な(それでも古めかしいが)レイヤ構造では、DIPは全く成立しないからだ。 P165で、わざわざ耳慣れないレイヤー「Policy Layer」「Mechanism Layer」「Utility Layer」を出しているのはそのためである。こうしたレイヤ構造はかなり一般的ではない。著者は持論を証明したいが為に、一般的ではないレイヤ構造をわざわざ引き合いに出しているだけである。


== 所有権の逆転 ==

DIPは間違っている

書籍「アジャイルソフトウェア開発の奥義」(ロバートCマーチン著、瀬谷啓介訳)の第一版のP163からの記述「依存関係逆転の原則(DIP)」は間違っているか、あるいは議論に混乱が見られる。ネット上にはこれを無批判に引用する日本語記事が多々存在するのだが、彼らは全くその内容を吟味も理解もしていないと思われる。

DIP原則とは

著者の説明はこうである。

  • 上位モジュールは下位モジュールに依存してはならない。どちらのモジュールも抽象に依存すべきである。
  • 「抽象」はその実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。

という。ここで、「上位モジュールは下位モジュールに依存してはならない」は間違いである。

そもそも上位・下位モジュールの定義が明確ではない(「アプリケーションの方針を決めている上位モジュール、実装の詳細を担当する下位レベルのモジュール」のみの説明)のだが、著者の意図としてはこうだろう。

  • 上位モジュール:使う側
  • 下位モジュール:使われる側

反論1

これに対する反論の一つとしてはこうだ。あるアプリケーションの構築と同時に、他のアプリケーションにも使用可能なライブラリを開発することにしたとする。こうした場合、これらのライブラリが上位モジュールである「アプリケーション」に依存してしまっては可搬性がなくなってしまう。したがって、「ライブラリ部分」と、その上位である「それ以外のアプリケーション部分」は、上位が下位に依存するという構造にならざるを得ない。

そしてこれは、同著で後述されている(P331)安定依存の原則(SRP)にも合致していると考えられる。つまり、著者自身が矛盾しているのである。

反論2

しかし、「この原則はライブラリ作成のようなケースを除外している」と反論されてしまうかもしれない。それでは以下のようなケースはどうだろうか。

例えば、三層アーキテクチャを考えてみる。これはUI層、ビジネスロジック層、データベース層に分かれる。一般的には、これらはソケットを介した何らかのプロトコルによって接続される複数のプログラムになると思われるが、別に一つのアプリとして開発してはいけない法はない。

この場合、UI層がビジネスロジック層に依存することになるが、これがいけないという理由は全く無いどころか、むしろ推奨されるべきものである。「そもそも我々が再利用したいと思っているのは、方針を決めている上位モジュールの方である」と著者は主張するが、そうではない。下位であるビジネスロジックの方を再利用したいこと、あるいは再利用すべきことは明らかであろう。

著者の想定は時代錯誤

反論2からもわかるように、著者の想定はそもそも古すぎるのである。どういうわけか、この章で著者は、20年以上も前の古めかしいソフトウェア設計を前提にしているのである。著者はP164で主張している。「事実、従来の手法の目標の一つは、上位モジュールから下位モジュールの呼び出し方を定義したプログラムの階層構造を作ることなのだ」。現代のソフトウェアではそうとはいえない。

P165で、わざわざ耳慣れないレイヤー「Policy Layer」「Mechanism Layer」「Utility Layer」を出しているのはそのためである。こうしたレイヤ構造はかなり一般的ではない。著者は持論を証明したいが為に、一般的ではないレイヤ構造をわざわざ引き合いに出しているだけである。

所有権の逆転