随着扩展方法的出现,抽象类的吸引力会降低吗？

Question

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

Answer 1

您可以使用哪些扩展方法来专注于实际应该执行的抽象类.在抽象类中实现"实用程序"代码是一种诱惑,因为它将被实现者使用,即使它可能不是逻辑继承树的一部分.扩展方法允许您将这些实用程序方法附加到接口,而不会使您的抽象基类混乱.

编辑

具体来说,我会应用这些指南.

遗产

• 如果行为是基类逻辑行为的一部分,请使用继承
• 如果行为是横切的,则不要使用继承(适用于对象层次结构之外的事物).这些将需要重复.

实用类

• 如果行为在逻辑上不属于它所处理的类,请使用实用程序类(静态类)
• 如果它们修改了它所作用的对象的内部状态,请不要使用实用程序类.应仅为对象实现层次结构保留状态修改.

扩展方法

• 对于扩展方法,请使用与实用程序类相同的决策,因为它们可以减少摩擦.如果采用扩展方法感觉不太自然,请不要这样做.
• 请使用扩展方法将实用程序添加到您无法控制的类(如字符串).
• 当行为被它所扩展的类消耗时,请勿使用扩展方法.虽然有可能做到这一点,但感觉做作
• 不要因为可以使用扩展方法.事实上,除非你必须,否则不要偏离旧的老式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());
}