Моя відповідь: поганий вибір дизайну. ;-)
Це цікава дискусія, зосереджена на синтаксичному впливі. Ядро аргументу, на мою думку, полягає в тому, що проектне рішення призвело до герметичних статичних класів. Зосередження уваги на прозорості імен статичного класу, що з’являються на верхньому рівні замість того, щоб ховатися («плутати») за дочірніми іменами? Можна зобразити мовну реалізацію, яка могла б отримати доступ до основи або дитини безпосередньо, збиваючи з пантелику.
Псевдо-приклад, припускаючи статичне успадкування, було визначено певним чином.
public static class MyStaticBase
{
SomeType AttributeBase;
}
public static class MyStaticChild : MyStaticBase
{
SomeType AttributeChild;
}
призведе до:
// ...
DoSomethingTo(MyStaticBase.AttributeBase);
// ...
що може (впливатиме?) на той самий накопичувач
// ...
DoSomethingTo(MyStaticChild.AttributeBase);
// ...
Дуже заплутано!
Але зачекайте! Як компілятор матиме справу з MyStaticBase та MyStaticChild, які мають однаковий підпис у обох? Якщо дитина переорієнтовано, ніж мій приклад вище, НЕ змінить ту саму сховище, можливо? Це призводить до ще більшої плутанини.
Я вважаю, що існує сильне обґрунтування інформаційного простору для обмеженого статичного успадкування. Більше про обмеження найближчим часом. Цей псевдокод показує значення:
public static class MyStaticBase<T>
{
public static T Payload;
public static void Load(StorageSpecs);
public static void Save(StorageSpecs);
public static SomeType AttributeBase
public static SomeType MethodBase(){/*...*/};
}
Тоді ви отримуєте:
public static class MyStaticChild : MyStaticBase<MyChildPlayloadType>
{
public static SomeType AttributeChild;
public static SomeType SomeChildMethod(){/*...*/};
// No need to create the PlayLoad, Load(), and Save().
// You, 'should' be prevented from creating them, more on this in a sec...
}
Використання виглядає так:
// ...
MyStaticChild.Load(FileNamePath);
MyStaticChild.Save(FileNamePath);
doSomeThing(MyStaticChild.Payload.Attribute);
doSomething(MyStaticChild.AttributeBase);
doSomeThing(MyStaticChild.AttributeChild);
// ...
Людині, яка створює статичну дитину, не потрібно думати про процес серіалізації, доки вони розуміють будь-які обмеження, які можуть бути поставлені на механізмі серіалізації платформи чи середовища.
Статистика (одиночні та інші форми "глобалів") часто виникає навколо сховища конфігурації. Статичне успадкування дозволило б подібному розподілу відповідальності чітко представити в синтаксисі, щоб відповідати ієрархії конфігурацій. Хоча, як я показав, є великий потенціал для масової неоднозначності, якщо реалізувати основні концепції статичного успадкування.
Я вважаю, що правильним вибором дизайну було б дозволити статичне успадкування з певними обмеженнями:
- Ніякої переоцінки нічого. Дитина не може замінити базові атрибути, поля чи методи, ... Перевантаження повинно бути нормальним, якщо існує різниця в підписі, що дозволяє компілятору розбирати дочір та базу.
- Дозволити лише загальні статичні бази, ви не можете успадковувати негенеричну статичну базу.
Ви все ще можете змінити той самий магазин через загальну посилання MyStaticBase<ChildPayload>.SomeBaseField. Але вас не відволікає, оскільки загальний тип повинен був би бути вказаний. У той час як еталонний дитина буде чистіше: MyStaticChild.SomeBaseField.
Я не письменник-компілятор, тому я не впевнений, чи пропускаю щось про труднощі реалізації цих обмежень у компіляторі. З цього приводу я переконаний, що в інформаційному просторі потрібна обмежена статична спадщина, і основна відповідь полягає в тому, що ви не можете через поганий (або надто простий) вибір дизайну.