让构造函数返回承诺是不好的做法吗？

Question

让构造函数返回承诺是不好的做法吗？

我正在尝试为一个博客平台创建一个构造函数，它的内部有许多异步操作。这些内容包括从目录中抓取帖子、解析它们、通过模板引擎发送它们等等。

所以我的问题是，让我的构造函数返回一个承诺而不是他们调用的函数的对象是不明智的吗？new反对。

例如：

var engine = new Engine({path: '/path/to/posts'}).then(function (eng) {
   // allow user to interact with the newly created engine object inside 'then'
   engine.showPostsOnOnePage();});

现在，用户也可能不提供补充承诺链：

var engine = new Engine({path: '/path/to/posts'});// ERROR// engine will not be available as an Engine object here

这可能会造成问题，因为用户可能会混淆为什么 engine 施工后不可用。

在构造函数中使用允诺的理由是合理的。我希望整个博客在建设阶段之后都能正常运行。但是，在调用之后，似乎几乎无法立即访问该对象。new.

我一直在争论用一些类似于engine.start().then()或engine.init()而不是回报承诺。但这些看起来也很难闻。

编辑：这是在一个Node.js项目中。

Answer 1

我遇到了同样的问题，并想出了这个简单的解决方案。与其从构造函数中返回承诺，不如将其放入this.initialization财产，如下所示：function Engine(path) {   var engine = this   engine.initialization = Promise.resolve()     .then(function () {       return doSomethingAsync(path)     })     .then(function (result) {       engine.resultOfAsyncOp = result    })}然后，在初始化后运行的回调中包装每个方法，如下所示：Engine.prototype.showPostsOnPage = function () {   return this.initialization.then(function () {     // actual body of the method   })}从API使用者的角度来看：engine = new Engine({path: '/path/to/posts'})engine.showPostsOnPage()这是因为您可以向一个承诺注册多个回调，它们要么在它解决后运行，要么在附加回调时运行(如果已经解决了)。这就是为什么蒙戈斯金起作用了，只是它实际上不使用承诺。编辑：自从我写了这个回复后，我就爱上了ES6/7语法，所以还有另一个例子。你今天可以和Babel一起用。class Engine {   constructor(path) {     this._initialized = this._initialize()   }   async _initialize() {     // actual async constructor logic   }   async showPostsOnPage() {     await this._initialized    // actual body of the method   }}编辑*您可以在节点7和--harmony旗子！

Answer 2

为了避免关注点的分离，使用工厂来创建对象。class Engine {     constructor(data) {         this.data = data;     }     static makeEngine(pathToData) {         return new Promise((resolve, reject) => {             getData(pathToData).then(data => {               resolve(new Engine(data))             }).catch(reject);         });     }}