Итак, «наследование» статического
члены просто выглядит как пространство имен
загрязнение
Это верно, за исключением того, что загрязнение одного парня является добавленным пряным ароматом другого парня.
Я думаю, что Мартин Фаулер в своей работе над DSL предложил использовать наследование таким образом, чтобы обеспечить удобный доступ к статическим методам, позволяя использовать эти методы без указания имени класса. Таким образом, вызывающий код должен находиться в классе, который наследует класс, в котором определены методы. (Я думаю, что это гнилая идея.)
По моему мнению, статические члены не должны смешиваться в классе с нестатической целью, и проблема, которую вы поднимаете здесь, является одной из причин, почему важно не смешивать их.
Скрытие закрытых статических изменяемых данных внутри реализации в противном случае «экземпляра» класса особенно ужасно. Но тогда есть статические методы, которые еще хуже смесителей. Вот типичное использование статических методов, смешанных в классе:
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, который возвращает Thing, а не AnotherThing.
Такое несоответствие строго подразумевает, что все, что связано со статическими методами, должно быть запечатано. Статические члены не могут хорошо интегрироваться с наследованием. Нет смысла иметь их наследственными. Поэтому я храню статические вещи в отдельных статических классах и жалею о необходимости избыточного объявления каждого члена статическим, когда я уже сказал, что класс статический.
Но это только одна из тех вещей, которые слишком поздно. Все реальные, рабочие языки (и библиотеки, и продукты) имеют несколько из них. В C # замечательно мало.