随着扩展方法的出现，抽象类的吸引力是否降低了？

发布于 2024-07-14 17:17:01 字数 462 浏览 5 评论 0原文

.NET 中扩展方法的一个有趣的方面是您可以将它们应用到接口。对我来说，我可以在接口附近定义功能，而无需定义使程序集混乱的抽象类，这似乎很好。

我知道抽象类并没有过时，但是您对在代码中利用这种副作用有何看法？

例子：

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

原文

One interesting aspect of extension methods in .NET is the fact that you can apply them to interfaces. For me, it seems nice that I can define functionality near the interface without defining an abstract class that clutters the assembly.

I know that abstract classes are not obsolete or anything, but how do you feel about utilizing this side effect in your code?

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

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

萌酱 2024-07-21 17:17:01

扩展方法可以让您专注于抽象类实际应该做什么。在抽象类中实现“实用”代码是一种诱惑，因为即使它可能不是逻辑继承树的一部分，它也会被实现者使用。扩展方法允许您将这些实用程序方法附加到接口，而不会弄乱您的抽象基类。

编辑

具体来说，我将应用这些准则。

继承

如果行为是基类逻辑行为的一部分，请务必使用
继承；如果行为是横切的（适用于对象层次结构之外的事物），请勿使用继承。这些将需要重复。

实用程序类

如果行为在逻辑上不属于其所作用的类，则应使用实用程序类（静态类）
。如果实用程序类修改其所作用的对象的内部状态，请勿使用实用程序类。状态修改应该仅为对象实现层次结构保留。

扩展方法

确实对扩展方法使用与对实用程序类相同的决策，因为它们会产生更少的摩擦。如果采用扩展方法感觉不太自然，请不要这样做。
请使用扩展方法向您无法控制的类（例如字符串）添加实用程序。
当行为由其扩展的类使用时，请勿使用扩展方法。虽然可以这样做，但感觉做作，
不要仅仅因为可以就使用扩展方法。事实上，除非您必须这样做，否则不要偏离老式的 OOP。然而，当你不得不这样做时，扩展方法是一个相对有用且无害的决定。

编辑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());
}

What extension methods lets you do is to focus in on what abstract classes should actually be doing. There's a temptation to implement "utility" code in abstract classes because it will be used by implementers even though it may not be part of the logical inheritance tree. Extension methods let you attach these utility methods to the interface without cluttering up your abstract base classes.

EDIT

Specifically, I would apply these guidelines.

Inheritance

DO use inheritance if the behavior is part of the logical behavior of the base class
DO NOT use inheritance if the behavior is cross-cutting (applies to things outside of your object hierarchy). These will require duplication.

Utility Classes

DO use utility classes (static classes) if the behavior does not logically belong to the class it's acting on
DO NOT use utility classes if they modify the internal state of the object it's acting on. State modification should be reserved only for the object implementation hierarchy.

Extension Methods

DO use the same decision for extension methods as you would for utility classes when they create less friction. If adopting extension methods feels less natural, don't do it.
DO use extension methods to add utility to classes you don't have control over (like string).
DO NOT use extension methods when the behavior is consumed by the class it is extending. While it is possible to do it, it feels contrived
DO NOT use extension methods just because you can. In fact don't deviate from good old fashioned OOP unless you have to. When you have to, however, extension methods are a relatively uesful and harmless decision to make.

EDIT 2

Thought of another DO for extension methods

DO use extension methods to provide a natural language (internal DSL) for certain implementations. Here's a silly example.

int age = getAge();
if (age.IsDraftAge() && !age.IsLegalDrinkingAge())
{
    Console.WriteLine(@"You cannot drink until your birthdate on {0}.
Join the army instead.",
                      age.GetYearWhenGettingDrunkIsOk());
}

回复收藏 0 原文