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

问题描述

全部

想了解一下这个想法。最近，在设计/开发时，我越来越成为纯粹主义DI / IOC原则的用户。这个部分（很大一部分）涉及确保我的课程之间几乎没有耦合，并且它们的依赖通过构造函数解决（有一些其他的方法来管理这个，但是你可以得到这个想法）。

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

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

  public static class StringExtensions 
 {
 public static string TruncateToSize（此字符串输入，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方法的用户，你是否避免使用扩展方法？

解决方案

我看到你来自哪里，但是，如果您试图嘲笑扩展方法的功能，我相信您使用它们不正确。应该使用扩展方法来执行在没有它们的情况下语法上不方便的任务。您的TruncateToLength是一个很好的例子。

测试TruncateToLength不会嘲弄它，它只需要创建一些字符串，并测试该方法实际返回正确值

另一方面，如果您在数据层中包含访问数据存储的扩展方法中的代码，那么是的，您有问题和测试将会成为一个问题。

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

All,

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).

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

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

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.

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?

解决方案

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.

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屋！