Comments 11
хороший способ композиции, но надо соблюдать какие-нибудь name conventions чтобы одна примесь не помешала другой (не перезаписала) что-либо выполнить в рамках контекста this. js в данном случае не плюнет никаким exception'ом.
А еще можно использовать для этого декораторы, которые предложили для ES7 и уже давно есть в babel.
Вот пример:
Вот пример:
// create-mixin.js
function createMixin(obj) {
return (SomeClass) => {
Object.assign(SomeClass.prototype, obj);
};
}
// mixins/say-hello.js
const SayHelloMixin = createMixin({
sayHello() {
console.log(this.name);
}
});
// human.js
@SayHelloMixin
class Human {
constructor(name) {
this.name = name;
}
}
const nkt = new Human('nkt');
nkt.sayHello();
Синтаксический сахар, это i++.
С class'ами мы, наконец, можем программировать имея в голове только предметную область, а не думая параллельно, как правильно состыковать прототипы с конструкторами. А то, что под капотом всё те же прототипы, так можно и всё назвать сахаром над машинными командами.
С class'ами мы, наконец, можем программировать имея в голове только предметную область, а не думая параллельно, как правильно состыковать прототипы с конструкторами. А то, что под капотом всё те же прототипы, так можно и всё назвать сахаром над машинными командами.
А раньше не могли?
А то, что под капотом прототипы — это прекрасно. Это позволяет использовать оба подхода одновременно.
А то, что под капотом прототипы — это прекрасно. Это позволяет использовать оба подхода одновременно.
>А раньше не могли?
Раньше, если совсем без всяких обёрток, параллельно с предметной областью нужно было в голове держать низкоуровневую реализацию и следить за тем, чтобы все свойства типа «constructor», «prototype» были правильно установлены.
>А то, что под капотом прототипы — это прекрасно. Это позволяет использовать оба подхода одновременно.
В JS вообще любую вещь можно десятком разных способов сделать.
По моему скромному мнению, это не так чтобы преимущество.
Хотя многие, конечно, думают иначе.
Раньше, если совсем без всяких обёрток, параллельно с предметной областью нужно было в голове держать низкоуровневую реализацию и следить за тем, чтобы все свойства типа «constructor», «prototype» были правильно установлены.
>А то, что под капотом прототипы — это прекрасно. Это позволяет использовать оба подхода одновременно.
В JS вообще любую вещь можно десятком разных способов сделать.
По моему скромному мнению, это не так чтобы преимущество.
Хотя многие, конечно, думают иначе.
Установка prototype затруднений не вызывает.
C constructor — отдельная тема. Спецификация неудобна. С точки зрения эксплуатации было бы лучше, чтобы constructor устанавливалось в каждый объект конструктором, а не наследовалось из прототипа, но встроенные объекты сделаны иначе. Увы.
Конечно, без обёртки большой проект не напишешь, посмотрим, как приживётся нативный class.
На счёт прототипов — я в последнее время думаю над такой обёрткой, которая позволила бы удобно использовать оба варианта, причём, чтобы с прототипом тоже можно было работать, и это предсказуемо влияло на отнаследованные от него объекты. Ну, например, у меня несколько комбо-боксов с общим списком, логично было бы положить список в общий прототип группы комбо-боксов, и менять его там, организовав реакцию наследников на его изменения. Пока чёткой архитектуры (а главное — удобного API) для этого не выдумал, но обязательно выдумаю.
C constructor — отдельная тема. Спецификация неудобна. С точки зрения эксплуатации было бы лучше, чтобы constructor устанавливалось в каждый объект конструктором, а не наследовалось из прототипа, но встроенные объекты сделаны иначе. Увы.
Конечно, без обёртки большой проект не напишешь, посмотрим, как приживётся нативный class.
На счёт прототипов — я в последнее время думаю над такой обёрткой, которая позволила бы удобно использовать оба варианта, причём, чтобы с прототипом тоже можно было работать, и это предсказуемо влияло на отнаследованные от него объекты. Ну, например, у меня несколько комбо-боксов с общим списком, логично было бы положить список в общий прототип группы комбо-боксов, и менять его там, организовав реакцию наследников на его изменения. Пока чёткой архитектуры (а главное — удобного API) для этого не выдумал, но обязательно выдумаю.
Своя обёртка для классов, это, конечно, полезное упражнение для ума.
Но в последнее время это уже несколько моветон.
Уже и ECMA новый и TypeScript и всё остальное. Лучше на что-то другое силы тратить.
Но в последнее время это уже несколько моветон.
Уже и ECMA новый и TypeScript и всё остальное. Лучше на что-то другое силы тратить.
Sign up to leave a comment.
Прототипы это объекты (и почему это важно)