什么时候创建扩展方法是正确的?
我有一段如下代码:
public class ActivityHelper
{
public void SetDate(IList<Activity> anActivityList)
{
foreach(Activity current in anActivityList)
{
current.Date = DateTime.Now;
}
}
//More methods, properties, fields, etc...
}
这可以很容易地转换为扩展方法。例如:
public static void SetDate(this IList<Activity> aList)
{
foreach(Activity current in anActivityList)
{
current.Date = DateTime.Now;
}
}
原始函数不使用 ActivityHelper 类中的任何实例特定数据或方法,这使得它看起来像是位于不正确的位置。现在是编写扩展方法的正确时间吗?创建扩展方法的正确场景是什么?
I have a piece of code like the following:
public class ActivityHelper
{
public void SetDate(IList<Activity> anActivityList)
{
foreach(Activity current in anActivityList)
{
current.Date = DateTime.Now;
}
}
//More methods, properties, fields, etc...
}
This could easily be converted to an extension method. For example:
public static void SetDate(this IList<Activity> aList)
{
foreach(Activity current in anActivityList)
{
current.Date = DateTime.Now;
}
}
The original function doesn't use any instance specific data or methods from the ActivityHelper class which makes it seem like it is in the incorrect place. Is this the correct time to write an extension method? What are the correct scenarios in which to create extension methods?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
Brad Adams 撰写了有关 的文章扩展方法设计指南:
Brad Adams has written about extension method design guidelines:
我认为只有当有令人信服的理由使该方法成为扩展方法时,扩展方法才是合适的。
如果该类型是您无法控制的类型,并且该方法应该看起来是该类型的组成部分,或者如果有令人信服的理由不将该方法直接放在该类型上(例如创建不需要的依赖项),则可以使用扩展方法可能是合适的。
就个人而言,如果 API 用户的期望已经是在处理 Activity 集合时使用“ActivityHelper”类,那么我可能不会为此创建扩展方法。标准的非扩展方法实际上是一个更简单的 API,因为它很容易理解和发现。从使用的角度来看,扩展方法很棘手 - 您调用的方法“看起来”存在于其他地方,而不是实际存在的地方。虽然这可以简化语法,但会降低可维护性和可发现性。
I think Extension methods are only appropriate if there is a compelling reason to make the method an extension method.
If the type is one you do not control, and the method should appear to be integral to the type, or if there is a compelling reason to not put the method directly on the type (such as creating an unwanted dependency) then an extension method could be appropriate.
Personally, if the expectation of the user of your API will already be to use the "ActivityHelper" class when working with collections of Activities, then I would probably not create an extension method for this. A standard, non-extension method will actually be a simpler API, since it's easily understood and discoverable. Extension methods are tricky from a usage standpoint - you're calling a method that "looks like" it exists somewhere other than where it actually exists. While this can simplify syntax, it reduces maintainability and discoverability.
根据我的经验,扩展方法在满足以下条件时效果最佳:
string.NormalizeUrl()
并不合适,因为并非所有字符串都是 URL)In my experience extension methods work best when they:
string.NormalizeUrl()
is not appropriate because not all strings are even URLs anyway)嗯,我通常创建扩展方法来帮助我编写流畅的代码。它通常取决于您创建的方法。
如果您觉得该方法应该已经在框架中并且太笼统,那么可以为此创建一个扩展方法。
但是您需要首先分析您正在扩展的类将始终处于您的扩展方法可以处理的状态。
有关 Brad 文章的指南
http://blogs.msdn.com/b/brada/archive/2009/01/12/framework-design-guidelines-extension-methods.aspx
Well i usually create extension methods to help me write codes which have a smooth flow. Its generally depends upon the method you are creating.
If you feel that the method should have already been in framework and is too general then its okay to create an extension method for that.
But you need to first analyze that the class you are extending will always will be in state that your extension method can handle.
For Guidelines here to Brad's Article
http://blogs.msdn.com/b/brada/archive/2009/01/12/framework-design-guidelines-extension-methods.aspx
本质上,扩展方法为 Helper 方法提供了更流畅的样式语法。这转化为看似向类型或接口的所有实现添加功能的能力。
但是,我通常会避免使用
void
返回类型来声明扩展方法,因为我觉得这种流畅的样式语法(允许您编写语句)的有用性在相关方法不使用时就被否定了。返回任何东西。不过,我想让 IntelliSense 拾取你的方法会很方便......:-)
In essence, Extension Methods provide a more fluent style syntax for Helper methods. This translates into the ability to seemingly add functionality to types or all implementations of interfaces.
However, I generally steer away from declaring Extension Methods with a
void
returntype, as I feel the usefulness of this fluent style syntax, which allows you to compose statements, is negated when the method in question doesn't return anything.However, I guess it can be handy to have your methods picked up by IntelliSense... :-)