相关疑难解决方法(0)

所有,

想要对此有所了解.最近,我在设计/开发时越来越多地成为"纯粹的"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方法的类(可以很容易地模拟).

从我的角度来看,前两个示例依赖于静态依赖(一个显式,一个隐藏),而第二个反转依赖性并提供减少的耦合和更好的可测试性.

那么扩展方法的使用是否与DI/IOC原则相冲突？如果您是IOC方法的订阅者,您是否避免使用扩展方法？