.NET 中扩展方法的一个有趣的方面是您可以将它们应用到接口。对我来说,我可以在接口附近定义功能,而无需定义使程序集混乱的抽象类,这似乎很好。
我知道抽象类并没有过时,但是您对在代码中利用这种副作用有何看法?
Example:
public static class IUserExtensions
{
public static bool IsCurrentUser(this IUser user)
{
return (HttpContext.Current.User != null &&
HttpContext.Current.User.Identity.Name == user.ID.ToString());
}
}
public interface IUser {
int ID { get; set; }
}
扩展方法可以让您专注于抽象类实际应该做什么。在抽象类中实现“实用程序”代码是一种诱惑,因为即使它可能不是逻辑继承树的一部分,它也会被实现者使用。扩展方法允许您将这些实用程序方法附加到接口,而不会弄乱您的抽象基类。
EDIT
具体来说,我会应用这些准则。
遗产
- 如果行为是基类逻辑行为的一部分,请务必使用继承
- 如果行为是横切的(适用于对象层次结构之外的事物),请勿使用继承。这些将需要重复。
实用程序类
- 如果行为在逻辑上不属于它所作用的类,请使用实用程序类(静态类)
- 如果实用程序类修改了其所作用的对象的内部状态,请勿使用它们。应保留状态修改only对于对象实现层次结构。
扩展方法
- 当扩展方法产生的摩擦较小时,请对扩展方法使用与对实用程序类相同的决定。如果采用扩展方法感觉不太自然,请不要这样做。
- 请使用扩展方法向您无法控制的类(例如字符串)添加实用程序。
- 当行为由其扩展的类使用时,请勿使用扩展方法。虽然有可能做到这一点,但feels做作的
- 不要仅仅因为可以就使用扩展方法。事实上,不要偏离好的老式 OOP,除非你have to。然而,当你不得不这样做时,扩展方法是一个相对有用且无害的决定。
EDIT 2
扩展方法的另一个 DO 的想法
请使用扩展方法为某些实现提供自然语言(内部 DSL)。这是一个愚蠢的例子。
int age = getAge();
if (age.IsDraftAge() && !age.IsLegalDrinkingAge())
{
Console.WriteLine(@"You cannot drink until your birthdate on {0}.
Join the army instead.",
age.GetYearWhenGettingDrunkIsOk());
}
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)