Почему конструкторы не наследованы?
Вот несколько вещей, которые вы могли бы сделать:
Экспортировать const из модуля . В зависимости от вашего варианта использования вы можете просто:
export const constant1 = 33;
И импортировать это из модуля, где это необходимо. Или, опираясь на свою идею статического метода, вы можете объявить static get accessor :
const constant1 = 33,
constant2 = 2;
class Example {
static get constant1() {
return constant1;
}
static get constant2() {
return constant2;
}
}
Таким образом, вам не нужны скобки:
const one = Example.constant1;
Затем, как вы говорите, поскольку class является просто синтаксическим сахаром для функции, вы можете просто добавить свойство без записи например:
class Example {
}
Object.defineProperty(Example, 'constant1', {
value: 33,
writable : false,
enumerable : true,
configurable : false
});
Example.constant1; // 33
Example.constant1 = 15; // TypeError
Может быть приятно, если бы мы могли просто сделать что-то вроде:
class Example {
static const constant1 = 33;
}
Но, к сожалению, этот синтаксис свойства класса в предложении ES7, и даже тогда он не позволит добавить const к свойству.
5 ответов
Иногда, при разделении на подклассы, Вы хотите ограничить условия, требуемые создать экземпляр класса.
Позволяют мне дать Вам пример. Если бы классы действительно наследовали своих конструкторов суперкласса, все классы имели бы конструктора без параметров от Object. Очевидно, это не корректно.
Если бы Вы думаете о том, что произошло бы, если бы конструкторы были наследованы, необходимо начать видеть проблему.
Как почти каждый тип в.NET наследовался Объекту (который имеет конструктора без параметров), который означает почти каждый тип, который Вы создаете, был бы вынужден иметь конструктора без параметров. Но существуют многие типы, где конструктор без параметров не имеет смысла.
также была бы проблема с управлением версиями. Если бы новая версия Вашего базового типа появляется с новым конструктором, Вы автоматически получили бы нового конструктора в своем производном типе. Это было бы плохой вещью и определенным экземпляром проблема хрупкого базового класса .
существует также более философский аргумент. Наследование об обязанностях по типу (это - то, что я делаю). Конструкторы о сотрудничестве типа (это - то, в чем я нуждаюсь). Так наследовавшиеся конструкторы смешали бы ответственность за тип с сотрудничеством типа, тогда как те два понятия должны действительно остаться отдельными.
Конструкторов в суперклассах вызывают, называете ли Вы явно их или нет. Они объединяют в цепочку от родительского класса вниз. Если Ваш конструктор явно не призывает конструктора, это - суперкласс тогда, конструктора по умолчанию в том классе называют неявно перед кодом Вашего конструктора.
Я предполагаю, что Вы имеете в виду:
class Foo
{
public Foo(int someVar) {}
}
class Bar : Foo
{
// Why does Bar not automatically have compiler generated version of
Bar(int someVar): Foo(someVar) {}
}
я полагаю, что это наследовано от C++ (и Java).
, Но принятие у Вас действительно было это, и Панель имела некоторые другие членские переменные. Был бы это не представить posability компилятора генерировало конструктора accdently быть используемым и не инициализация членов ПАНЕЛИ.
Конструктора по умолчанию будут всегда называть.
class Bar : Foo { }
, Когда Панель инстанцируют, она назовет Нечто () конструктором по умолчанию.
class Foo {
public Foo(int someVar) {}
}
class Bar : Foo {
public Bar() : base(42) {}
}
, Если нет конструктора без параметров, Вы будете обязаны определять который использовать и передать параметры.