11

मुझे हाल ही में प्रक्षेपण मॉड्यूल पैटर्न से परिचित हो गया है और मैंने इसके बारे में कुछ लेख पढ़े हैं।मॉड्यूल पैटर्न के नुकसान का खुलासा

यह एक बहुत अच्छा पैटर्न जैसा प्रतीत होता है और मैं इसे एक बड़ी परियोजना में उपयोग करना शुरू करना चाहता हूं। प्रोजेक्ट में मैं उपयोग कर रहा हूं: Jquery, KO, requirejs, Jquery Mobile, JayData। ऐसा लगता है कि यह केओ व्यू मॉडल्स के लिए एक अच्छा फिट होगा।

विशिष्ट में मैं THIS संस्करण का उपयोग करना चाहता हूं।

एक चीज़ जो मुझे नहीं मिल सका, इस पैटर्न का उपयोग करने के लिए नुकसान हैं, ऐसा इसलिए है क्योंकि कोई भी नहीं है (मुझे विश्वास करना मुश्किल लगता है)?

इसका उपयोग शुरू करने से पहले मुझे क्या विचार करना चाहिए?

+2

इस आलेख को जांचें: http://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript अंत में एक नुकसान अनुभाग है। – nemesv

+0

परिभाषित मॉड्यूल पैटर्न मॉड्यूल पैटर्न और प्रकटन पैटर्न के साथ कुछ नुकसान भी प्राप्त करता है (जैसे रिटर्न स्टेटमेंट के लिए तंग युग्मन, सार्वजनिक और निजी कार्यों को कैसे घोषित किया जाता है, निजी और सार्वजनिक सबराउटिन के लिए गैर-घोषणात्मक नामस्थान, और किसी ऑब्जेक्ट का मिश्रित उपयोग रिटर्न कथन के साथ शाब्दिक): http://github.com/tfmontague/definitive-module-pattern – tfmontague

उत्तर

4

मैंने इस लेख को पढ़ा है कि @nemesv ने मुझे संदर्भित किया (धन्यवाद :)) और मुझे लगता है कि एक और नुकसान है जिसका उल्लेख नहीं किया गया था, इसलिए मैंने सोचा कि मैं इसे संदर्भ के लिए यहां जोड़ दूंगा।

नुकसान

इस पद्धति का एक नुकसान यह है कि एक पैच है अगर एक निजी समारोह को एक सार्वजनिक समारोह, कि सार्वजनिक समारोह ओवरराइड नहीं किया जा सकता है संदर्भित करता है, तो है: यहाँ लेख से एक उद्धरण है ज़रूरी। ऐसा इसलिए है क्योंकि निजी फ़ंक्शन निजी कार्यान्वयन को संदर्भित करेगा और पैटर्न केवल सार्वजनिक सदस्यों पर लागू नहीं होता है, केवल कार्यों के लिए।

सार्वजनिक ऑब्जेक्ट सदस्य जो निजी चर का उल्लेख करते हैं वे उपरोक्त नो-पैच नियम नोट्स के अधीन हैं।

इस के परिणामस्वरूप खुलासा मॉड्यूल पैटर्न के साथ बनाया मॉड्यूल, मूल मॉड्यूल पैटर्न के साथ बनाई गई उन लोगों की तुलना में अधिक नाजुक हो सकता है तो देखभाल के उपयोग के दौरान लिया जाना चाहिए।

और मेरे अलावा:

आप इस पैटर्न साथ भाग का उपयोग नहीं कर सकते हैं।

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

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

InheritingObj.prototype = new Obj(); 

InheritingObj.prototype.constructor = InheritingObj; 

इस js में विरासत के लिए एक सरल उदाहरण है, लेकिन जब Revealing Prototype Pattern का उपयोग कर आप ऐसा करने की आवश्यकता होगी: उदाहरण के लिए:

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

आप विरासत को पार कर जाएगी जो।

+0

ऐसा लगता है जैसे यह ऑब्जेक्ट.क्रेट (urlbuilder) के साथ पूरी तरह से काम करता है; विरासत करने का एक और तरीका इस तरह से है http://jsfiddle.net/d0n7kfmx/ आपको क्या लगता है? – user2734550

13

प्रकटीकरण मॉड्यूल पैटर्न (आरएमपी) उन वस्तुओं को बनाता है जो ओवरराइडिंग के संबंध में अच्छा व्यवहार नहीं करते हैं। नतीजतन, आरएमपी का उपयोग करके बनाई गई वस्तुओं प्रोटोटाइप के रूप में अच्छी तरह से काम नहीं करते हैं। तो यदि आप ऐसी वस्तुओं को बनाने के लिए आरएमपी का उपयोग कर रहे हैं जो विरासत श्रृंखला में उपयोग किए जा रहे हैं, तो बस नहीं। प्रकटीकरण प्रोटोटाइप पैटर्न के उन समर्थकों के विरोध में यह दृष्टिकोण मेरा स्वयं का है।

बुरा विरासत व्यवहार देखने के लिए URL बिल्डर का निम्न उदाहरण लेते हैं,:,

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

    return { 
    urlBase: _urlBase, 
    build: _build 
    } 
} 

कारण है कि आप कोई निजी घटकों के साथ एक वस्तु के लिए आरएमपी का प्रयोग करेंगे के सवाल अलग स्थापना ध्यान दें कि यदि आप लौटे ऑब्जेक्ट को लें और "http://stackoverflow.com" के साथ urlBase को ओवरराइड करें, आप उम्मीद करेंगे कि बिल्ड() को उचित रूप से बदलने के व्यवहार की अपेक्षा करें। यदि ऐसा नहीं होता है, तो निम्न के रूप में देखा:

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" 

कंट्रास्ट निम्नलिखित URL निर्माता कार्यान्वयन

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" 

जो सही ढंग से कार्य के साथ व्यवहार।

आप में के रूप में इस दायरे का उपयोग करके खुलासा मॉड्यूल पैटर्न के व्यवहार को सही कर सकते निम्नलिखित

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

    return { 
    urlBase: _urlBase, 
    build: _build 
    } 
} 

लेकिन वह नहीं बल्कि खुलासा मॉड्यूल पैटर्न के प्रयोजन को हरा दिया। अधिक जानकारी के लिए अपने ब्लॉग खुलासा मॉड्यूल पैटर्न के साथ पोस्ट http://ilinkuo.wordpress.com/2013/12/28/defining-return-object-literals-in-javascript/

-2

अन्य नुकसान को देखने में शामिल हैं:

  1. वापसी बयान के साथ सार्वजनिक कार्यों के तंग युग्मन
  2. वस्तु का मिश्रित उपयोग सार्वजनिक कार्य करता है और के लिए शाब्दिक निजी कार्यों
  3. के लिए स्टैंडअलोन घोषणाओं

मैं खुलासा मॉड्यूल पैटर्न से अधिक निश्चित मॉड्यूल पैटर्न का उपयोग कर की सलाह देते हैं (https://github.com/tfmontague/definitive-module-pattern)

+0

मैं इस पैटर्न की अनुशंसा नहीं करता क्योंकि यह खुलासा मॉड्यूल पैटर्न से काफी अलग नहीं है। स्वीकार्य उत्तर में ओवरराइड और प्रोटोटाइप के संबंध में यह वही कमियां साझा करता है। –

+0

प्रश्न प्रकटन मॉड्यूल पैटर्न के नुकसान के बारे में था। यह मॉड्यूल पैटर्न का उपयोग करने के फैसले के बारे में नहीं था। – tfmontague

संबंधित मुद्दे