C # статическое наследование членов - почему оно вообще существует?

Итак, «наследование» статических членов просто выглядит как загрязнение пространства имен.

Это верно, за исключением того, что загрязнение одного парня - это добавление пряностей другим парнем.

Я думаю, что Мартин Фаулер в своей работе над 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, который возвращает Thing, а не AnotherThing.

Такое несоответствие настоятельно подразумевает, что все, что используется статическими методами, должно быть запечатано. Статические члены плохо интегрируются с наследованием. Нет смысла делать их наследуемыми. Поэтому я храню статические вещи в отдельных статических классах, и я недовольна тем, что излишне объявлять каждый член статическим, когда я уже сказал, что класс статический.

Но это всего лишь одна из тех вещей, о которых сейчас уже слишком поздно. Все настоящие рабочие языки (и библиотеки, и продукты) имеют несколько из них. В C # их очень мало.

У меня скорее есть доступ ко всем моим базовым статическим членам в производных классах. В противном случае мне нужно было бы точно знать, где был определен статический член, и вызывать его явно.

При использовании Intellisense вы можете автоматически узнать каждый статический член, доступный для этого класса.

Конечно, они не передаются по наследству, это просто ярлык

Вот как это работает, в большинстве случаев, наверное, был бы глупым ответом. Но в данном случае это работает так; поскольку вы производите от A, вы говорите, что вы A + добавляемые вами дополнительные функции.

Следовательно, вам необходимо иметь доступ к тем же переменным, что и через экземпляр A.

Однако наследование статического класса не имеет смысла, в то время как доступ к статическим членам / полям / методам имеет.

Примером этого является следующее:

internal class BaseUser
{
    public static string DefaultUserPool { get; set; }
}
internal class User : BaseUser
{
    public int Id { get; set; }
    public string Name { get; set; }
    public User Parent { get; set; }
}

Где тест выглядит так:

User.DefaultUserPool = "Test";
BaseUser.DefaultUserPool = "Second Test";

Console.WriteLine(User.DefaultUserPool);
Console.WriteLine(BaseUser.DefaultUserPool);

Обе строки WriteLines выводят «Второй тест», потому что и BaseUser, и User должны использовать DefaultUserPool, по замыслу. А переопределение статических реализованных методов не имело бы большого смысла, поскольку это всего лишь метод доступа в дочернем классе.

Там может быть только один. Его переопределение будет означать, что для этого подкласса существует новая реализация, которая убьет термин «статический».

Собственно, насколько я понимаю, это всего лишь ярлык, предоставленный компилятором. Синтаксический сахар. B.M() просто компилируется в A.M(), поскольку B не имеет static M(), а A имеет. Это для облегчения написания, не более того. Нет никакого «статического наследования».

Добавлено: И требование для new при "переопределении" просто так, чтобы вы случайно не прострелили себе ногу.

Я думаю, это для доступа к защищенным статическим членам базового класса.

class Base
{
    protected static void Helper(string s)
    {
       Console.WriteLine(s);
    }
}

class Subclass : Base
{
   public void Run()
    {
       Helper("From the subclass");
    }
}

Я всегда вижу в этом способ предотвратить любую форму полиморфизма наследуемым классом тех элементов, которые вы хотите сохранить одинаковую функцию для всех дочерних классов.

игнорируйте приведенное выше, по какой-то причине я думал о запечатанном, а не о статическом

Я предполагаю, что вы должны использовать статические переменные-члены и функции, чтобы гарантировать, что любые данные или функциональность не зависят от экземпляра класса, поскольку он будет создан только один раз.

Примером использования может быть значение счетчика, которое будет вести текущий счет всех экземпляров подклассов суперкласса (каждый подкласс увеличивает значение статического счетчика при построении). Это значение счетчика будет доступно и одинаково для всех экземпляров подкласса.

Итак ... Какая альтернатива?

В вопросе упоминается ...

почему компилятор не сообщает об ошибке? В конце концов, в B нет метода M ...

Но есть производный метод M в классе B.

Если бы компилятор не представил программисту единую виртуальную таблицу для базовых случаев, тогда программисту пришлось бы искать статические методы среди базовых типов. Это нарушило бы полиморфизм.

Википедия ...

Полиморфизм подтипа, почти повсеместно называемый просто полиморфизмом в контексте объектно-ориентированного программирования, - это способность одного типа, A, появляться и использоваться как другой тип, B ....

В строго типизированных языках полиморфизм обычно означает, что тип A каким-то образом является производным от типа B или что тип C реализует интерфейс, представляющий тип B.