C#静态成员“继承"- 为什么这会存在? [英] C# static member "inheritance" - why does this exist at all?

问题描述

在 C# 中，超类的静态成员被继承"到子类作用域中.例如:

In C#, a superclass's static members are "inherited" into the subclasses scope. For instance:

class A { public static int M() { return 1; } }
class B : A {}
class C : A { public new static int M() { return 2; } }
[...]
A.M(); //returns 1
B.M(); //returns 1 - this is equivalent to A.M()
C.M(); //returns 2 - this is not equivalent to A.M()

现在，你不能继承静态类，我能想象到静态继承可能很重要的唯一地方完全忽略了它:尽管你可以创建一个需要类型参数 T 的通用约束作为A的子类，你仍然不能调用TM()(这可能为VM简化了事情)，更不用说写一个不同的M在子类中实现并使用它.

Now, you can't inherit static classes, and the only place I can imagine that static inheritance might matter ignores it entirely: although you can make a generic constraint that requires a type parameter T to be a subclass of A, you still cannot call T.M() (which probably simplifies things for the VM), let alone write a different M implementation in a subclass and use that.

所以，静态成员的继承"看起来只是命名空间污染；即使您明确限定了名称(即 B.M)A 的版本仍然被解析.

So, the "inheritance" of static members merely looks like namespace pollution; even if you explicitly qualify the name (i.e. B.M) A's version is still resolved.

编辑与命名空间比较:

Edit compare with namespaces:

namespace N1{  class X();   }
namespace N1.N2 {  class X();   }
namespace N1.N2.N3 { [...] }

在N1.N2.N3 内，如果我不加限定地使用X，它指的是N1.N2.X 是有道理的.但是如果我明确引用 N1.N2.N3.X - 并且不存在这样的类 - 我不希望它找到 N2 的版本；如果您尝试这样做，确实编译器会报告错误.相比之下，如果我明确引用B.M()，为什么编译器不报错?毕竟，B"中没有M"方法......

Within N1.N2.N3 It makes sense that if I use X without qualification it refers to N1.N2.X. But if I explicitly refer to N1.N2.N3.X - and no such class exists - I don't expect it to find N2's version; and indeed to compiler reports an error if you try this. By contrast, if I explicitly refer to B.M(), why doesn't the compiler report an error? After all, there's no "M" method in "B"...

这个继承有什么目的?能否以某种方式建设性地使用此功能?

What purpose does this inheritance have? Can this feature be used constructively somehow?

推荐答案

所以，静态的继承"成员只是看起来像命名空间污染

So, the "inheritance" of static members merely looks like namespace pollution

没错，只是一个人的污染是另一个人添加的辣味.

That's right, except that one guy's pollution is another guy's added spicy flavouring.

我认为 Martin Fowler 在他的 DSL 工作中建议以这种方式使用继承来方便地访问静态方法，允许在没有类名限定的情况下使用这些方法.因此，调用代码必须位于继承定义方法的类的类中.(我认为这是一个烂主意.)

I think Martin Fowler, in his work on DSLs, has suggested using inheritance in this way to allow convenient access to static methods, allowing those methods to be used without class name qualification. So the calling code has to be in a class that inherits the class in which the methods are defined. (I think it's a rotten idea.)

在我看来，不应将静态成员混入具有非静态目的的类中，您在此处提出的问题是不混用它们很重要的部分原因.

In my opinion, static members should not be mixed into a class with a non-static purpose, and the issue you raise here is part of the reason why it's important not to mix them.

在其他实例"类的实现中隐藏私有静态可变数据特别可怕.但是还有静态方法，它们是更糟糕的混合器.下面是混合到类中的静态方法的典型用法:

Hiding private static mutable data inside the implementation of an otherwise "instancey" class is particularly horrible. But then there are static methods, which are even worse mixers. Here's a typical use of static methods mixed into a class:

public class Thing
{
    // typical per-instance stuff
    int _member1;
    protected virtual void Foo() { ... }
    public void Bar() { ... }

    // factory method
    public static Thing Make()
    {
        return new Thing();
    }
}

这是静态工厂方法模式.大多数时候它毫无意义，但更糟糕的是现在我们有了这个:

It's the static factory method pattern. It's pointless most of the time, but even worse is that now we have this:

public class AnotherThing : Thing { }

现在有一个静态的 Make 方法，它返回一个 Thing，而不是一个 AnotherThing.

This now has a static Make method which returns a Thing, not a AnotherThing.

这种不匹配强烈暗示任何带有静态方法的东西都应该被密封.静态成员无法与继承很好地集成.让它们遗传是没有意义的.因此，我将静态事物保存在单独的静态类中，并且当我已经说过该类是静态的时，我抱怨不得不将每个成员声明为静态的冗余.

This kind of mismatch strongly implies that anything with static methods should be sealed. Static members fail to integrate well with inheritance. It makes no sense to have them heritable. So I keep static things in separate static classes, and I gripe about redundantly having to declare every member static when I've already said that the class is static.

但这只是为时已晚的事情之一.所有真正的工作语言(以及库和产品)都有其中的一些.C# 的数量非常少.

But it's just one of those too-late-now things. All real, working languages (and libraries, and products) have a few of them. C# has remarkably few.

这篇关于C#静态成员“继承"- 为什么这会存在?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！