このとき、矢印はBを中心にしていて、制御の向き(AがCを利用する)に対してCからBについては反転しているということに過ぎない。DIPで解決すべき問題が2種類あるにも関わらず、説明が出現箇所によって1種類しか行わないために、おれにはすごくわかりにくかった。1点は、循環参照に関する問題で、オブジェクトは相互作用するので、CからAへの呼出しもあり得るという点だ。aself)となっていることを意味し、つまり循環参照となり破綻するという問題をどう解決するか(ここまで還元してしまうと全体としては正しくないのだが、SOLIDのDの説明としては一番正しいと思う)ということだ。ところが、11章でDIPについて詳細の説明っぽいものがあるのだが、この例がわかりにくい。依存関係にある下位モジュールは外部のものであるはずなのに、依存している(useする)モジュール側にファクトリやインターフェイスを置いているからだ。11章に出てくる図はこの図で正しいために、DIPで実際に実現したいことがぼやけているように思える。DIPで解決する2点目として、外部モジュールを交換可能とすることが出てくる。このためには、本来直接useすべき(→が外部モジュールへ向く)依存関係を、内部のインターフェイスに向け、内部のインターフェイスというかプロクシを利用することで(プロクシは直接の外部モジュールと内部モジュールの中間に配置する)依存関係としては外部モジュールが内部のインターフェイスに依存しているように扱うようにする。中間層はオーバーヘッドなので、薄ければ薄いほどよく、ここで外部モジュールといったものがシステムの一部であれば、呼出し元のインターフェイスに依存させる(というのが11章の図)、ということだった(19章では明確になっているが、ここのコード例もひどい。Rubyのmixin可能なモジュールをプラギンとして扱えば、19章の悪いコード例そのもので正しく設計しているということもあり得る)。ここでぐちゃぐちゃ書いていることの重要性についての認識はアンクルボブとおれとで全く疑問の余地もなく同じだとは思う。DIPを設計に組み込んでおくことで、外部コンポーネントのプラグイン化が実現できるからだ。通常、プラグインは、メインとなるモジュールが公開するインターフェイスに合わせて後刺しするモジュールを後から開発する。なく、既存のモジュールをプラギンとして少ない労力で交換可能とすることで、すべての外部にあるモジュール(フレームワークであったりミドルウェアであったり)を交換可能とする。ここでも依存関係が逆転できているのがミソとなる。これによって、すべての外部に存在するインフラストラクチャをプラギン化できるように考慮する=すべてを詳細として設計本体から切断可能とする、という画だ。この考えが正しいのは、ビジネスは永く、ソフトウェアの流行は短いからだ。ゼロから作り直すのは常に危険だということでもある。その観点から、もっとも必要な抽象エンティティというのは、実はドキュメント(自然言語で記述された)ではないかということになって、おそらくそれは正しいのだがさすがにそれを言うとある意味おしまい的なところがあるのか、そうは書いていない。以下その他気づいた点のメモ。図14-9はあえてそうしているのかも知れないが、StableにI=1の記述が抜けているので、それまで説明したIという変数の意味が不明になると思う。StableのIが1となるため、instableからのI=1の矢印に対してIの値が等しいので違反、と示す必要があるのではなかろうか。上でも書いているが、悪いコード例がくそだ。エンティティとはビジネスルール(という抽象)で、ユースケースはアプリケーション(という具象)。後半以降エンティティという言葉ががんがん出てくるのだが、ECB(エンティティ、コントローラ、バウンダリー)のEなので、本書の他のパート同様抽象のように扱われているのだが、実際にはコンポーネントだったり実装だったりもするので明確ではないが、この箇所でエンティティを独立したコンポーネントまたは抽象としているように読めたということらしい。正しいというかおもしろい。フレームワーク作者の自尊心よりも、設計を重視しろというのがおもしろい。ViewModelを忘れたようだ(とメモしているが、ViewModelも詳細なのでどうでも良い話だった)。ドメイン(とここでは記述しているが、P.192あたりでのエンティティ群のこと)を別コンポーネントとしてフレームワーク(=インフラストラクチャ)から分離している画が出てきているので、おれの読み方と考え方と合致していることが確認できた。第34章はサイモン・ブラウンという人がアンクルボブのクリーンアーキテクチャを元に、自分の世界と擦り合わせて改変することを説明している。これはとても良い本だなというのが、この箇所で完璧に明らかになる。教条主義ほどくだらないものはないからね。publicの用語としての使用方法が気に食わない。本書を読む場合は、最初に付録Aの思い出話を流し読みするのが良いと思う。古臭いことを書いているが、重要なのは、その時代のシステム制約とソフトウェア、そこで発生した開発上の問題と現実(運用上)の問題、あるとすれば解決の発見、ないとすれば次の時代へ持ち越された問題の本質、そういったことから、どういうモチベーションで本書が書かれているかと、ソフトウェア開発はハードウェアとコンピュータサイエンスの発展によって助けられながらもどうも同じことを繰り返しているようだ(当然、問題も持ち越されているようだ)ということを念頭に入れたり、自分のケースに引き寄せたりすることで、本文が読みやすくなると思う。正弘)抽象度合いが高いので、そう簡単には古びない良い本だと思う。(古びさせないために、あえて極端に古い例を出しているのか?と疑問に思うところもある(12章)が、温故知新を肝に銘じているのかも知れない)特に、無敵にプログラミングしている(というかプログラミングできる)20代とかのうちに読むと良いのではないかと思った。開発している間は読む価値大いにある。電子書籍で買うなら達人出版会が良いと思う。PDF(EPUBもある)だし。