私は最近、Robert.C.Martinの優れた本AgilePrincipals、Patterns and Practices in C#の依存性逆転の原則について読みました。しかし、この原則には、私が完全には理解していないと感じる側面が1つあります。
ロバートは、高レベルのモジュールが低レベルのモジュールに依存している場合、低レベルのモジュールを変更すると、高レベルのモジュールも変更される可能性があると説明しています。彼は次の例でこれを示しています。
public class Button
{
private Lamp lamp;
public void Poll(){
if(/*some condition*/)
Lamp.TurnOn();
}
}
このコードについてRobertは、「ButtonクラスはLampクラスに直接依存しています。この依存関係は、ButtonがLampへの変更の影響を受けることを意味します」と述べています。
私が見ているように、Lampクラスに加える可能性のある変更には2つの種類があります。
1)パブリックインターフェイスに影響を与えずに、クラスの内部実装を変更したい場合があります。
2)パブリックインターフェイスを変更して、TurnOnメソッドにパラメータを渡すことを決定する場合があります。
私が理解していないのは、最初のケースでは、なぜ変更によってButtonクラスが変更されるのでしょうか。ランプへのパブリックインターフェイスは変更されていませんが、なぜボタンを変更する必要があるのでしょうか。
2番目のケースでは、ボタンを変更する必要があることがわかります。しかし、この場合、抽象化に応じてこれをどのように変更しますか?確かに、インターフェイスをランプに変更する正当な理由がある場合は、ランプとボタンが依存する抽象化のインターフェイスも変更します。この場合、依存する抽象化が変更されたため、とにかくボタンを変更する必要があります。
高レベルのモジュールの再利用性、高レベルのモジュールによるインターフェイスの所有権、実行時に依存関係の実装を選択する機能など、DIPには他にも利点があることを認識していますが、DIPが依存の必要性をどのように減らすかを理解するのに苦労しています下位レベルのモジュールへのインターフェイスが変更されたときに変更するモジュール、および/または依存モジュールの内部変更が上位レベルのモジュールの変更を引き起こす可能性がある理由。