11

Ich habe mich kürzlich mit dem Muster des Revealing Moduls vertraut gemacht und ich habe einige Artikel darüber gelesen.Offensichtliche Modulmuster Nachteile

Es scheint wie ein sehr gutes Muster und ich möchte es in einem großen Projekt, das ich habe, verwenden. In dem Projekt verwende ich: Jquery, KO, requires, Jquery Mobile, JayData. Es scheint mir, als ob es gut zu den KO ViewModels passt.

Im speziellen möchte ich THIS Version davon verwenden.

Eine Sache, die ich nicht finden konnte, sind Nachteile für die Verwendung dieses Musters, ist es, weil es keine gibt (ich kann es kaum glauben)?

Was sollte ich beachten, bevor ich es benutze?

+2

Überprüfen Sie diesen Artikel: http://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript gibt es eine Nachteile Abschnitt am Ende. – nemesv

+0

Das Definitive-Modul-Muster überwindet auch einige Nachteile des Modulmusters und des Enthüllungsmusters (z. B. enge Kopplung mit der return-Anweisung, wie öffentliche und private Funktionen deklariert werden, nicht deklarative Namespaces für private und öffentliche Subroutinen und gemischte Verwendung eines Objekts) Literal mit der return-Anweisung): http://github.com/tfmontague/definitive-module-pattern – tfmontague

Antwort

4

Ich habe den Artikel gelesen, auf den @Nemesv mich verwiesen hat (Danke :)) und ich denke, dass es einen weiteren Nachteil gibt, der nicht erwähnt wurde, also dachte ich, ich würde ihn hier als Referenz hinzufügen. Hier ist ein Zitat aus dem Artikel:

Nachteile

Ein Nachteil dieses Musters ist, dass, wenn eine private Funktion eine öffentliche Funktion verweist, dass die öffentliche Funktion nicht außer Kraft gesetzt werden kann, wenn ein Patch ist notwendig. Dies liegt daran, dass die private Funktion weiterhin auf die private Implementierung verweist und das Muster nicht auf öffentliche Member nur für Funktionen gilt.

Öffentliche Objektelemente, die sich auf private Variablen beziehen, sind ebenfalls , die den obigen no-patch-Regeln entsprechen.

Daher können Module, die mit dem Muster des Revealing-Moduls erstellt wurden, zerbrechlicher sein als solche, die mit dem ursprünglichen Modul erstellt wurden. Daher sollten Sie während der Verwendung vorsichtig vorgehen.

Und mein Zusatz:

Sie können nicht Erbe mit diesem Muster verwenden. Zum Beispiel:

var Obj = function(){ 
    //do some constructor stuff 
} 

var InheritingObj = function(){ 
    //do some constructor stuff 
} 

InheritingObj.prototype = new Obj(); 

InheritingObj.prototype.constructor = InheritingObj; 

Dies ist ein einfaches Beispiel für die Vererbung in js, aber wenn die Revealing Prototype Pattern verwenden Sie dies tun müssen:

InheritingObj.prototype = (function(){ 
    //some prototype stuff here 
}()); 

, die werden Sie Vererbung außer Kraft setzen.

+0

Es scheint wie es perfekt funktioniert mit Object.create (urlBuilder); Eine andere Möglichkeit, die Vererbung zu machen, ist auf diese Weise http://jsfiddle.net/d0n7kfmx/ was denkst du? – user2734550

13

Das Aufdeckende Modulmuster (RMP) erzeugt Objekte, die sich nicht in Bezug auf Übersteuerung gut verhalten. Folglich funktionieren Objekte, die mit dem RMP erstellt wurden, nicht gut als Prototypen. Wenn Sie also RMP verwenden, um Objekte zu erstellen, die in einer Vererbungskette verwendet werden sollen, tun Sie das nicht. Diese Sichtweise ist meine eigene, im Gegensatz zu jenen Befürwortern des Enthüllungsprototypmusters.

Um das schlechte Vererbungsverhalten, nehmen Sie das folgende Beispiel einer URL Builder zu sehen:

function rmpUrlBuilder(){ 
    var _urlBase = "http://my.default.domain/"; 
    var _build = function(relUrl){ 
    return _urlBase + relUrl; 
    }; 

    return { 
    urlBase: _urlBase, 
    build: _build 
    } 
} 

Abgesehen von der Frage, warum Sie RMP für ein Objekt ohne privaten Komponenten verwenden würden, beachten Sie, dass, wenn Sie nimm das zurückgegebene Objekt und überschreibe urlBase mit "http://stackoverflow.com", du würdest erwarten, dass sich das Verhalten von build() entsprechend ändert. Es ist nicht, wie im folgenden zu sehen:

var builder = new rmpUrlBuilder(); 
builder.urlBase = "http://stackoverflow.com"; 
console.log(builder.build("/questions"); // prints "http://my.default.domain/questions" not "http://stackoverflow.com/questions" 

Kontrast das Verhalten mit der folgenden URL Builder Implementierung

function urlBuilder = function(){ 
    return { 
    urlBase: "http://my.default.domain/". 
    build: function(relUrl){ return this.urlBase + relUrl;} 
    } 
} 

var builder = new urlBuilder(); 
builder.urlBase = "http://stackoverflow.com"; 
console.log(builder.build()); // prints "http://stackoverflow.com/questions" 

die korrekt verhält.

können Sie korrigieren das Aufdecken Verhalten des Moduls Muster durch diesen Bereich, wie in der

function rmpUrlBuilder(){ 
    var _urlBase = "http://my.default.domain/"; 
    var _build = function(relUrl){ 
    return this.urlBase + relUrl; 
    }; 

    return { 
    urlBase: _urlBase, 
    build: _build 
    } 
} 

folgenden verwenden, aber dass Niederlagen eher den Zweck des Revealing Modul-Muster. Weitere Einzelheiten finden Sie in meinem Blog http://ilinkuo.wordpress.com/2013/12/28/defining-return-object-literals-in-javascript/

-2

Andere Nachteile, die mit der Aufdecken Modul Pattern Post gehört:

  1. enge Kopplung der öffentlichen Funktionen mit der Return-Anweisung
  2. Mischnutzung von Objektliteral für öffentliche Aufgaben und Standalone-Erklärungen für private Veranstaltungen

ich würde empfehlen, das endgültige Module Muster über das Aufdecken Modul Muster mit (https://github.com/tfmontague/definitive-module-pattern)

+0

Ich würde dieses Muster nicht empfehlen, da es sich nicht wesentlich von dem aufschlussreichen Modulmuster unterscheidet. Es teilt die gleichen Mängel in Bezug auf Override und Prototyp wie in der angenommenen Antwort. –

+0

Die Frage bezog sich auf die Nachteile des Aufdeckenden Modulmusters. Es ging nicht um die Entscheidung, ein Modulmuster zu verwenden. – tfmontague

Verwandte Themen