我们开始使用C#(.NET 3.0),我想知道你们是如何使用扩展方法的?你什么时候使用它们?
此外,如果您还列出了使用它们的所有黑暗先决条件,我将不胜感激.
Mar*_*ell 58
使用扩展方法的时间:
作为第二点的例子; 你可能有一个扩展方法IList<T>(例如,Sort)可以完全使用现有IList<T>成员编写...所以为什么强迫任何人写任何东西?这是LINQ的基础块,并允许微软提供多不破坏任何东西更多的功能.
时间不使用扩展方法:
小智 24
扩展方法允许扩展现有类,而不依赖于继承或必须更改类的源代码.这意味着如果要在现有的String类中添加一些方法,可以非常轻松地完成.在决定是否使用扩展方法时,需要考虑以下几条规则:
扩展方法不能用于覆盖现有方法
将不会调用与实例方法具有相同名称和签名的扩展方法
扩展方法的概念不能应用于字段,属性或事件
谨慎使用扩展方法....过度使用可能是一件坏事!
小智 8
此链接http://geekswithblogs.net/BlackRabbitCoder/archive/2010/04/26/c-extension-methods---to-extend-or-not-to-extend.aspx 提供了有关何时使用扩展方法的良好指导什么时候不.
引用本文:
一个好的扩展方法应该:
- 应用于它扩展的任何类型的实例.
- 简化逻辑并提高可读性/可维护性.
- 适用于最适用的特定类型或接口.
- 在命名空间中隔离,以便它不会污染IntelliSense.
我有理由使用扩展方法.如果您控制一个类及其代码,通常不需要扩展方法.
如果不这样做,扩展方法可能会有用.
我经常使用扩展方法的一个地方是[Flags]枚举.当你有一个基于标志的枚举时,有一个相当大的表达式,用于确定枚举值是否设置了特定的标志.因此,每当我构建[Flags]枚举时,我都会构建以下扩展方法:
[Flags]
public enum MyEnum
{
    FlagA,
    FlagB,
    // etc.
}
public static class MyEnumExt
{
    public static bool HasFlags(this MyEnum item, MyEnum query)
    {
        return ((item & query) == query);
    }
}
这样我的代码看起来像:
MyEnum flags = MyEnum.FlagA;
if(flags.HasFlags(MyEnum.FlagA))
{
  // handle FlagA
}
而不是:
MyEnum flags = MyEnum.FlagA;
if((flags & MyEnum.FlagA) == MyEnum.FlagA)
{
  // handle FlagA
}
小智 5
老实说,我想说,当它不是一个好主意时,比当它是一个好主意时更容易解释。
我认为,扩展方法的主要好处是它们可以提高方法的采用率。这是因为用户不必实例化另一个类的实例即可使用您的方法,并且当开发人员正在为您正在扩展的类寻找方法时,智能感知将宣传您的方法。如果您试图让其他开发人员遵循公司的新标准,这一点可能很重要。
当考虑是否创建扩展方法时,请记住SOLID原则。
单一责任: - 你几乎总是至少使用扩展方法来改变单一责任原则,因为你正在附加已经是一个类的东西(你要么无法控制,要么太害怕接触)。
开放/关闭原则: - 扩展方法不能被重写,这意味着您的方法可能无法充分“开放扩展”。
L iskov 替换原则: - 如果您有任何类型的继承结构,您将无法在子类型上使用扩展方法。
接口隔离原则: - 尽管您可以“扩展”接口,但您必须为该扩展提供具体的实现。因此,您不能针对可以在不同上下文中以不同方式实现的接口进行编程(例如单元测试)
依赖倒置原则: - 如果您的代码有任何依赖关系,您将如何为工厂和单元测试公开这些依赖关系(依赖倒置原则)?
最后,扩展方法只是穿着新衣服的静态方法。因此,静态方法的所有困难(例如线程安全、垃圾收集等)在实现扩展方法时都会随之而来。
因此,我会认真考虑编写一个方法作为扩展,并重新考虑使用工厂和基本帮助器类。
如果您确实编写了扩展方法,请使其非常简单。尽量避免有任何依赖项(或将所有依赖项作为参数传递)。并注意如何在多线程环境中管理内存和锁定资源。
| 归档时间: | 
 | 
| 查看次数: | 24183 次 | 
| 最近记录: |