扩展方法是否隐藏依赖关系? [英] Do Extension Methods Hide Dependencies?

查看:28
本文介绍了扩展方法是否隐藏依赖关系?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

全部,

想对此有一些想法.最近,在设计/开发时,我越来越成为纯粹"DI/IOC 原则的订户.其中一部分(很大一部分)涉及确保我的类之间几乎没有耦合,并且它们的依赖关系通过构造函数解决(当然还有其他管理方法,但你明白了).

Wanted to get a few thoughts on this. Lately I am becoming more and more of a subscriber of "purist" DI/IOC principles when designing/developing. Part of this (a big part) involves making sure there is little coupling between my classes, and that their dependencies are resolved via the constructor (there are certainly other ways of managing this, but you get the idea).

我的基本前提是扩展方法违反了DI/IOC的原则.

My basic premise is that extension methods violate the principles of DI/IOC.

我创建了以下扩展方法,用于确保插入到数据库表中的字符串被截断为正确的大小:

I created the following extension method that I use to ensure that the strings inserted into database tables are truncated to the right size:

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);
    }
}

然后我可以像这样从另一个类中调用我的字符串:

I can then call my string from within another class like so:

string myString = "myValue.TruncateThisPartPlease.";
myString.TruncateToSize(8);

不使用扩展方法的公平翻译是:

A fair translation of this without using an extension method would be:

string myString = "myValue.TruncateThisPartPlease.";
StaticStringUtil.TruncateToSize(myString, 8);

使用上述任一示例的任何类都无法独立于包含 TruncateToSize 方法(TypeMock 除外)的类进行测试.如果我没有使用扩展方法,并且我不想创建静态依赖项,它看起来更像:

Any class that uses either of the above examples could not be tested independently of the class that contains the TruncateToSize method (TypeMock aside). If I were not using an extension method, and I did not want to create a static dependency, it would look more like:

string myString = "myValue.TruncateThisPartPlease.";
_stringUtil.TruncateToSize(myString, 8);

在最后一个示例中,_stringUtil 依赖项将通过构造函数解析,并且可以在不依赖实际 TruncateToSize 方法的类的情况下测试该类(它可以很容易地模拟).

In the last example, the _stringUtil dependency would be resolved via the constructor and the class could be tested with no dependency on the actual TruncateToSize method's class (it could be easily mocked).

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

From my perspective, the first two examples rely on static dependencies (one explicit, one hidden), while the second inverts the dependency and provides reduced coupling and better testability.

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

So does the use of extension methods conflict with DI/IOC principles? If you're a subscriber of IOC methodology, do you avoid using extension methods?

推荐答案

我知道你从哪里来,但是,如果你试图模拟扩展方法的功能,我相信你使用它们不正确.应该使用扩展方法来执行如果没有它们在语法上会很不方便的任务.您的 TruncateToLength 就是一个很好的例子.

I see where you are coming from, however, if you are trying to mock out the functionality of an extension method, I believe you are using them incorrectly. Extension methods should be used to perform a task that would simply be inconvenient syntactically without them. Your TruncateToLength is a good example.

测试 TruncateToLength 不涉及模拟它,它只涉及创建一些字符串并测试该方法是否实际返回了正确的值.

Testing TruncateToLength would not involve mocking it out, it would simply involve the creation of a few strings and testing that the method actually returned the proper value.

另一方面,如果您的数据层中有代码包含在访问数据存储的扩展方法中,那么是的,您遇到了问题,测试将成为问题.

On the other hand, if you have code in your data layer contained in extension methods that is accessing your data store, then yes, you have a problem and testing is going to become an issue.

我通常只使用扩展方法来为小而简单的操作提供语法糖.

I typically only use extension methods in order to provide syntactic sugar for small, simple operations.

这篇关于扩展方法是否隐藏依赖关系?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆