関心の分離としてのDI

オブジェクトは、他のオブジェクトの生成か、使用のいずれかのみを行い、双方を行ってはならない。
— 生成・使用分離の原則 – Strategic Choice

Eric Raymondは『Art of UNIX Programming』の中で、UNIX®哲学の幾つかを次のように指摘しています。

モジュラー化の原則: 単純な部分を書き、きれいなインターフェースで接続する
分離の原則: ポリシーを機構から分離し、インターフェースをエンジンから分離する
表現の原則: ナレッジをデータの中に入れ込むことによって、プログラム・ロジックは愚かで堅牢となるようにする

こうした考え方は古いものですが、私達は、こうした考えをJava™技術で実現するための新しい方法を発見し続けているのです。そして分離のための技術の最新版、DI（dependency injection: 依存性注入）は、上記の理想を反映したものです。

https://www.ibm.com/developerworks/jp/opensource/library/os-ag-ioc1/

生成・使用分離の原則

生成・使用分離の原則 – 時々聞くこの原則のそもそものソースは何だろうかと時々調べる事がありますが、それに巡り会えたことがありません。ついに見つけたのが流石Strategic Choiceブログなのですが、記事によると「名前がなかったので勝手につけました」…どうりで中々見つからないわけです。

しかし記事は明快です。

どうして？

この規則に従えば、作業分担が明確化され、結合度が低下する。

オブジェクトの使用は概念レベルを取り扱う。
オブジェクトの生成は具象レベルを取り扱う。
これらレベルの違うものを混ぜて設計すべきではない。
これらを分けて考えることで、それぞれに集中できる。

大変重要です。つまりこれが良く分離されたソースコードでは「概念レベルを取り扱う」ものと「具象レベルを取り扱う」コードが分離されています。

[具象コード]
[具象コード]
[具象コード]

[概念コード]
[概念コード]
[概念コード]

良いコード。これが分離されレイヤーになっています。対してその逆では..

[具象コード]
[具象コード]
[概念コード]
[具象コード]
[具象コード]
[概念コード]

クリアに説明されるとスッキリします。この善し悪しはイメージしやすいのではないでしょうか。ソースの可読性はスコープを狭くして細かく語られることも多いですが、このように大きなスコープでの設計原則が守られてるかという事も大事なのではないかと考えます。

DIの説明を時々料理に例えることがあります。レシピを見て、材料を揃え下ごしらえを済ませてから調理（runtime)に移ります。調理中には途中で材料を選んだり買い物をしなおしたりすることはありません。道具の準備や下ごしらを完了してから調理に移ります。準備と利用は分離され、分業も可能です。

BEAR.Sundayでもruntimeでは原則オブジェクトは用意されたものを利用するだけで、生成に関しての関心は極小化されています。runtimeでオブジェクトの生成方法をアプリケーションワイドなconfigから調べ作成する事は原則ありません。