随着扩展方法的出现，是抽象类的吸引力？ [英] With the advent of extension methods, are abstract classes less attractive?

问题描述

在.NET扩展方法的一个有趣的方面是，你可以将它们应用到接口。对于我来说，似乎很高兴，我可以定义界面附近的功能，而无需定义一个抽象类，杂波的程序集。

我知道，抽象类是没有过时或任何东西，但如何你觉得使用中的code这个副作用？

例如：

 公共静态类IUserExtensions
{
    公共静态布尔IsCurrentUser（此IUSER用户）
    {
        返程（HttpContext.Current.User = NULL和放大器;！＆安培;
                HttpContext.Current.User.Identity.Name == user.ID.ToString（））;
    }
}

公共接口IUSER {
    INT ID {获得;组; }
}
 

解决方案

什么扩展方法可以让你做的是集中在什么抽象类实际上应该做的事情。有一种诱惑，实行实用code在抽象类中，因为这将被用于执行者，尽管它未必是合乎逻辑的继承树的一部分。扩展方法让您可以将这些工具方法的接口不会搞乱你的抽象基类。

修改

具体而言，我将适用本准则。

继承

• 请使用继承，如果该行为是基类的逻辑行为
的一部分
• 请不要使用继承，如果该行为是跨领域（适用于事你的对象层次结构之外的）。这些都需要重复。

实用工具类

• 请使用实用工具类（静态类），如果该行为不逻辑上属于类它作用于
• 请不要使用实用工具类，如果他们修改它作用于对象的内部状态。国家修改应被保留的只有的为对象实施的层次结构。

扩展方法

• 请使用扩展方法相同的决定，你会为实用工具类，当他们创建更小的摩擦。如果采用扩展方法感觉不太自然，不这样做。
• 请使用扩展方法来添加实用程序类，你没有控制权（如字符串）。
• 请不要使用扩展方法时的行为是由它扩展的类消费。虽然这是可以做到的，它的感觉的做作
• 请不要使用扩展方法，只是因为你可以。其实不来自良好的老式OOP偏离，除非你的必须的。当你必须这样做，但是，扩展方法是一个相对uesful无害的决定。

编辑2

另一种思路做扩展方法

确实使用扩展方法，以提供一个自然语言（内部DSL）的某些实现。这是一个愚蠢的例子。

  INT年龄= getAge（）;
如果（age.IsDraftAge（）＆安培;＆安培;！age.IsLegalDrinkingAge（））
{
    Console.WriteLine（@你不能喝，直到你生日的{0}。
参军吧。
                      age.GetYearWhenGettingDrunkIsOk（））;
}
 

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

解决方案

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

这篇关于随着扩展方法的出现，是抽象类的吸引力？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！