Преимущества / недостатки передачи функции в конструктор Deferred

Question

Играя с Deferred's, я вижу много разных комбинаций использования. Большинство из них одинаковы, но иногда я вижу те, которые немного отличаются.

НАПРИМЕР...

НОРМАЛЬНО, ЭТО ВИДЕТЬ
Здесь мы просто используем отложенное.

// NORMALLY I SEE THIS...
function doSomething(){

    var deferred = $.Deferred();
    var myClass = new MyClass();

    myClass.doSomething(function () {
        deferred.resolve();
    });

    return deferred.promise();
};

СЛУЧАЙНО, ЭТО ВИДЕТЬ
Здесь мы передаем функцию в конструктор Deferred... затем используем ее.

// SOMETIMES I SEE THIS...
function doSomething() {

    var deferred = $.Deferred(function (deferred) {

        //Q: Is there an advantage to doing this instead?
        //Q: Is this a mis-use?
        var myClass = new MyClass();

        myClass.doSomething(function () {
            deferred.resolve();
        });
    });

    return deferred.promise();
};

МОЙ ВОПРОС:

• Есть ли преимущество в том, чтобы делать 2-й вместо этого?
• Это неправильное использование конструктора?
• Эта практика создает проблему, которую я еще не видел?

Я еще не видел каких-либо проблем, возникающих из метода 2. Итак, я ищу реальное понимание здесь.

Answer 1

Есть ли преимущество в том, чтобы делать 2-й вместо этого?

Нет, если вам не нравятся обратные вызовы, которые побеждают цель обещаний.

---

Это неправильное использование конструктора?

Нету. JQuery отложенный документ

jQuery.Deferred( [beforeStart ])

beforeStart
Type: Function( Deferred deferred )
A function that is called just before the constructor returns.

---

Эта практика создает проблему, которую я еще не видел?

Нет, это не так, если вы не собираетесь использовать myClass где-то еще, что будет невозможно, так как это определено в вашем обратном вызове.

Заключение:

В конце концов, это скорее личное предпочтение. Решение 1 кажется более чистым, если честно.