[設計思想] DIの使用場面・使用方法

kazuto — Mon, 02 Feb 2009 14:16:00 GMT

最近DI（Dependency Injection）やAOP（Acpect Oriented Programming）について凄く興味が出て勉強してます。
そこでDIコンテナや、AOPを実現する為の機能を趣味で作成しているのですが、いまいち理解出来ない事があります。

自分の認識としては、DIはクラス間の依存部分を外部へ排除し、依存部分を外部より注入する機構を適用し、管理・修正に強くするといった認識です。（すでにここから違うのか？）
まず再確認として下記のようなクラスがあるとします。

Employee

Public Class Employee
    Private shoutLogic As HardShoutLogic
    Public Sub Shout()
        shoutLogic = New HardShoutLogic()
        Console.WriteLine(shoutLogic.GetShoutString() & "叫ぶ～～！！！")
    End Sub
End Class

HardShoutLogic

Public Class HardShoutLogic
    Public Function GetShoutString() As String
        Return "激しく"
    End Function
End Class

従業員が叫ぶと言う事は別として、上記ではEmployeeを叫ばす為に、どのように叫ばすかを実装しているHardShoutLogicクラスが必要になってます。
Employeeクラス内でHardShoutLogicクラスのインスタンスが生成されていますので、EmployeeクラスはHardShoutLogicクラスに依存している事になります。
例えば、「激しく叫ぶ～～！」を「弱く叫ぶ・・・」にする為にはWeakShoutLogicクラスが必要になります。

WeakShoutLogic

Public Class WeakShoutLogic
    Public Function GetShoutString() As String
        Return "弱く"
    End Function
End Class

WeakShoutLogicクラスを使用すればEmployeeクラスは激しくも弱くも叫ぶ事が出来るようになりますが、依然Employeeクラスでは実装クラスを直接使用している為に、依存性が存在する事は無くなっていません。
ここで、インターフェイスとファクトリクラスを使用して、Employeeクラスから叫ぶ実装のインスタンス生成を排除して依存性を弱くします。

IShoutLogic

Public Interface IShoutLogic
Function GetShoutString() As String
End Interface

HardShoutLogic
（IShoutLogic実装版）

Public Class HardShoutLogic
    Implements IShoutLogic
    Public Function GetShoutString() As String Implements IShoutLogic.GetShoutString
        Return "激しく"
    End Function
End Class

WeakShoutLogic
（IShoutLogic実装版）

Public Class WeakShoutLogic
    Implements IShoutLogic
    Public Function GetShoutString() As String Implements IShoutLogic.GetShoutString
        Return "弱く"
    End Function
End Class

Employee
（ファクトリ使用版）

Public Class Employee
    Private shoutLogic As IShoutLogic
    Public Sub Shout()
        'ファクトリクラスを使用しIShoutLogic実装クラスを取得する
        shoutLogic = ShoutLogcFactory.GetShoutLogic()
        Console.WriteLine(shoutLogic.GetShoutString() & "叫ぶ～～！！！")
    End Sub
End Class

上記変更にてEmployeeクラスよりIShoutLogic実装クラスのインスタンス生成をファクトリクラスへカプセル化する事が出来ました。
これでIShoutLogic派生クラスの変更があってもファクトリクラスを修正するだけで良くなりました。

Seasar.NETをベースに話しをしますが、この状態からDIを使用し依存性を外部に出す場合、Seasar.NETのS2Container.NETを使用し外部ファイルベースのDIを適用するか、Quillを使用し属性ベースのDIを適用するかを選択する事になります。

疑問なのはここからです。

外部ファイルベースのS2Container.NETでは起動時にDI対象のインスタンスがDIコンテナによってインスタンス生成・管理が行われますが、起動時にDIのセットアップが行われる為、起動時のレスポンス等懸念が出る場合があります。
その反面、QuillではDI対象のオブジェクトが必要とされる場合にDIが適用される為、起動時のレスポンスをある程度排除する事が出来ます。
ですが、属性ベースのDI考え方は、「ステートレスな依存性の場合」とされてますが、ステートレス時のDI適用の場面ってどんな場面なのかが分かりません。

属性ベースでのDIの場合、インターフェイスと実装クラスが「１対１」という関係を作り、インターフェイスに実装クラスを指定する属性を指定します。

IShoutLogic
（属性指定によるDI）

<Implementation(GetType(HardShoutLogic))> _
Public Interface IShoutLogic
Function GetShoutString() As String
End Interface

この属性ベースのDI適用の場合、インターフェイスと実装クラスが「１対１」の関係とする必要がある為、この時点でインターフェイスの「必要性」が自分としては良く分かりません。

仮に実装クラスを変更する場合、IShoutLogicインターフェイスの属性を変更する必要がありますし、Employeeクラス内で実装クラスのHardShoutLogicクラスを直接生成している場合と、属性ベースのDIを使用している場合のメリット、デメリットが良くわかりません。
違うクラスではIShoutLogic実装クラスをファクトリクラスを使用して取得するような実装があったとしても、こっちではDI、あっちではファクトリクラスとするのも解りづらくなるし。

DIの適用場面など、皆さんはどのようにしてらっしゃいますか？