全て、
これについていくつか考えてみたいと思います。最近、私は設計/開発の際に「純粋主義者」の DI/IOC 原則のサブスクライバーになりつつあります。これの一部 (大部分) には、クラス間の結合がほとんどないこと、およびそれらの依存関係がコンストラクターを介して解決されることを確認することが含まれます (これを管理する方法は確かに他にもありますが、アイデアはわかります)。
私の基本的な前提は、拡張メソッドが DI/IOC の原則に違反しているということです。
データベーステーブルに挿入された文字列が適切なサイズに切り捨てられるようにするために使用する次の拡張メソッドを作成しました。
public static class StringExtensions
{
public static string TruncateToSize(this string input, int maxLength)
{
int lengthToUse = maxLength;
if (input.Length < maxLength)
{
lengthToUse = input.Length;
}
return input.Substring(0, lengthToUse);
}
}
次に、次のように別のクラス内から文字列を呼び出すことができます。
string myString = "myValue.TruncateThisPartPlease.";
myString.TruncateToSize(8);
拡張メソッドを使用せずにこれを公正に翻訳すると、次のようになります。
string myString = "myValue.TruncateThisPartPlease.";
StaticStringUtil.TruncateToSize(myString, 8);
上記の例のいずれかを使用するクラスは、TruncateToSize メソッドを含むクラスとは別にテストできませんでした (TypeMock は別として)。拡張メソッドを使用しておらず、静的な依存関係を作成したくない場合は、次のようになります。
string myString = "myValue.TruncateThisPartPlease.";
_stringUtil.TruncateToSize(myString, 8);
最後の例では、_stringUtil の依存関係がコンストラクターによって解決され、実際の TruncateToSize メソッドのクラスに依存せずにクラスをテストできます (簡単にモックできます)。
私の見解では、最初の 2 つの例は静的な依存関係 (1 つは明示的、もう 1 つは非表示) に依存していますが、2 番目の例は依存関係を逆転させ、結合を減らし、テスト容易性を高めています。
では、拡張メソッドの使用は DI/IOC の原則に反しますか? IOC 方法論のサブスクライバーである場合、拡張メソッドの使用を避けますか?