因此，静态成员的“继承”仅看起来像命名空间污染
没错，只是一个人的污染是另一个人的辛辣味。
我认为Martin
Fowler在有关DSL的工作中曾建议以这种方式使用继承，以允许方便地访问静态方法，从而允许使用这些方法而无需类名限定。因此，调用代码必须在继承定义方法的类的类中。（我认为这是一个烂主意。）
我认为，不应将静态成员混合到具有非静态目的的类中，并且您在此处提出的问题是不混合它们的重要性的部分原因。
将私有静态 可变 数据隐藏在否则为“ instancey”类的实现内部特别可怕。但是，还有静态方法，甚至是更差的混频器。这是混合使用静态方法的典型用法：
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(); }}这是静态工厂方法模式。在大多数时候，这毫无意义，但是更糟糕的是，现在我们有了这个：
public class AnotherThing : Thing { }现在，它具有一个静态
Make方法，该方法返回a
Thing而不是a
AnotherThing。
这种不匹配强烈暗示着任何带有静态方法的东西都应该密封。静态成员无法很好地与继承集成。让它们遗传是没有意义的。因此，我将静态事物保存在单独的静态类中，当我已经说过该类是静态的时，我不得不冗余地将每个成员声明为静态。
但这只是那些太迟了的事情之一。所有实际的工作语言（以及库和产品）都有其中一些。C＃很少。
