Наследование node.js предпочитает дочерние свойства конструктора

Question

var util = require('util');

function Entity(){
  //this.x == 10 at this point
  this.x = 0;
  this.y = 0;
  this.globalInit();
}

Entity.prototyp.globalInit = function(){
  console.log("this.x ", x);
};

function Actor(){
  this.x = 10;
  this.y = 10;
  Actor.super_.apply(this, arguments);
}

util.inherits(Entity, Actor);
var a = new Actor();
//outputs -> this.x 0

У меня есть эти два конструктора. Я хочу, чтобы свойства, определенные в дочернем конструкторе, были конечными свойствами. Я мог двигаться Actor.super_.apply наверх конструктора, но есть логика инициализации (globalInit) что я хочу сохранить в конце родительского конструктора

Answer 1

Я вижу два хороших решения этого. Во-первых, родительский конструктор может принимать параметры для x а также yи по умолчанию их значения родительского класса.

function Entity(x, y){
  this.x = typeof x === 'undefined' ? 0 : x;
  this.y = typeof y === 'undefined' ? 0 : y;
  this.globalInit();
}

function Actor(){
  Actor.super_.call(this, 10, 10);
}

Этот метод будет работать лучше всего, если свойств не очень много, и разрешить их передачу не проблема. Он несколько ломается, если инициализация очень сложна.

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

function Entity(){}
function Actor(){}

function createEntity(){
  var e = new Entity();
  e.x = 0;
  e.y = 0;
  e.globalInit();
  return e;
}

function createActor(){
  var a = new Actor();
  a.x = 10;
  a.y = 10;
  a.globalInit();
  return a;
}

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

Использование фабричных методов вместо непосредственного вызова конструктора также повышает ценность других способов. Это несколько разъединяет два модуля, так что потребитель этих Entities а также Actors не нужно знать, как правильно их построить. Это также позволяет вам иметь несколько разных "конструкторов" подписей без болезненного анализа аргументов.