[javascript] विरासत में मिली जावास्क्रिप्ट फ़ंक्शन को पुन: उपयोग और ओवरराइड करने के तरीके



Answers

अगर कोई सिर्फ कुछ कोड को चलाने के लिए चाहते हैं, जब onclick () को कहा जाता है, तो वह केवल उससे कनेक्ट हो सकता है ध्यान दें कि आप डोजो.कनेक्ट () के साथ न केवल फ़ंक्शन कॉल्स को कनेक्ट कर सकते हैं।

dojo.connect(obj, 'onclick', function(){
  // Some extra code that runs when obj.onclick() is called
});

अगर वह एक नया वर्ग बनाना चाहते हैं और इस this.inherited(arguments); को this.inherited(arguments); हुए this.inherited(arguments); यह करने का सबसे अच्छा तरीका है

Question

मेरे पास माउस इवेंट्स के लिए एक क्लास है मैं dojo बी / सी का उपयोग कर रहा हूँ मैं अपने ओ ओ दृष्टिकोण की तरह

dojo.declare("MouseObject", null, {
  constructor: function(){},
  onclick : function(){...},
  _onClick : function(){...}
});

_onClick() विंडो उत्पन्न माउस प्रेस / रिलीज़ इवेंट के लिए सुनता है और यह निर्धारित करता है कि कोई क्लिक हुई है या नहीं। यदि यह है, तो onClick() को कहा जाता है। onClick() सभी संभव क्लिकों के लिए सामान्य कार्यक्षमता प्रदान करता है, इसलिए इसे हर बार उपयोगकर्ता क्लिक करने की आवश्यकता होती है

कभी-कभी उपयोगकर्ता onClick() की कार्यक्षमता का विस्तार करना चाहते हैं onClick() क्या कोई चिपकाने के बिना मूल कार्यक्षमता को शामिल करने के लिए वैसे भी है? दो तरीकों से मैं सोच सकता हूं, न तो मुझे पसंद है, ये हैं

dojo.declare("MouseObjectChild", [MouseObject], {
  constructor: function(){},
  onclick : function(){this.inherited(arguments);...}
});

जिसकी कमियां है कि मुझे नई कक्षाएं बनानी पड़े हैं जिनकी वास्तव में जरूरत नहीं है, और दो एक मध्यवर्ती समारोह जोड़ते हैं

dojo.declare("MouseObject", null, {
      constructor: function(){},
      onclick : function(){this._onClick()...}, //child onClick
      _onClick : function(){...}, //parent onClick
      __onClick : function(){...} //listener
    });

लेकिन यह अच्छा कोड नहीं दिखता है

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

beforeDraw();
draw();
afterDraw();

क्या यह अच्छा डिजाइन माना जाता है? क्या मैं बजाय फ़ंक्शन पॉइंटर्स को एक सरणी में रखा और उन्हें क्रम में कॉल करना चाहिए?




अगर मैं आपका प्रश्न समझता हूं, तो आप विशिष्ट मामलों के लिए कार्यक्षमता को संशोधित करना चाहते हैं। अगर यह मामला है, और आप किसी भी ऊपरी भाग को नहीं चाहते हैं, तो मैं तत्काल तरीकों पर अधिरोपण विधियों पर भरोसा करूँगा।

ओवरराइड मॉडल

आपकी कक्षा :

dojo.declare("some.path.DrawingThing", [dijit._Widget], {
    draw: function () {
        this.inherited(arguments); // Call super class methods
        // override this method to do specialized things that're specific 
        // to an instance.
    }
});

ग्राहक इंस्टेंटिशन :

var drawer = new some.path.DrawingThing({
    draw: function () {
        beforeDraw();
        // Access the pre-existing functionality in a somewhat dirty way.
        this.constructor.prototype.draw.apply(this, arguments);
        afterDraw();
    }
});

यदि आप इस मॉडल का पालन करते हैं तो कम कोड है, लेकिन यह साफ नहीं है दूसरा विकल्प एक वास्तविक एपीआई लिखना है, नीचे देखें।

इवेंट मॉडल

यदि आप एक सच्चे एपीआई चाहते हैं, तो मैं घटनाओं को प्रदान करता हूं:

// Dojo 1.6 style declaration.
dojo.declare("some.path.DrawingThing", [dijit._Widget], {
    onBeforeDraw: function(){
        // Hook into this method to do something before draw
    },
    onDraw: function(){
        // Hook into this method to do something after draw
    },

    draw: function () {
        // This method is actually called when the draw even fires
        this.onBeforeDraw();
        this.inherited(arguments); // Call super class methods
        this.onDraw();
    }
});



आपके पास कई विकल्प हैं
1. वादा पैटर्न लोकप्रियता प्राप्त कर रहा है (हालांकि प्रतिस्पर्धी चश्मा हैं): http://wiki.commonjs.org/wiki/Promises/B jQuery का कार्यान्वयन बी के पास है और यह अच्छी तरह से प्रलेखित है। इसमें सबसे अधिक विकल्प हैं, यह मजबूत है, लेकिन पहले अपने सिर को लपेटना आसान नहीं है।

  1. एओपी-शैली प्रोग्रामिंग आपको सलाह के पहले और बाद के साथ बेला करने की अनुमति देती है। हालांकि, इसके लिए काम करने के लिए आपको बेनामी कार्यों में सब कुछ रोकना और यह तय करना होगा कि क्या आप कक्षा में क्षमता पकाने के बाद तत्कालता या योजना के बाद सलाह लागू करते हैं। यह कोड संरचना में अधिक योजना बना लेता है लेकिन उपयोगिता का एक टन प्रदान करता है।

उदाहरण के लिए:

var MYAPP = {
  onClick: function () {
    //do something...
  }
};

dojo.declare("MouseObject", null, {
  constructor: function(){},
  onclick : function(){...},
  _onClick : function(){
    return MYAPP.onClick.apply(this, arguments);
  }
});

चूंकि मेरी कक्षा हर बार MYAPP कॉल करती है (हां, इसके लिए एक स्कोपिंग चार्ज है), मैं मैआपपी को लटकने वाले फ़ंक्शन को हेरफेर कर सकता हूं और इसका इस्तेमाल करने वाले किसी भी व्यक्ति को लाभ होगा।

MYAPP.after("onClick", function () {...}); //lots of ways to write .after, just google some AOP js or use a library

दूसरी ओर:

var MYAPP = {
  onClick: function () {
    //do something...
  }
};

dojo.declare("MouseObject", null, {
  constructor: function(){},
  onclick : function(){...},
  _onClick : MYAPP.onClick
});

अब मैं MYAPP को नहीं बदल सकता और माउसऑब्जेक्ट या इसके उदाहरणों में परिवर्तन देख सकता हूं क्योंकि फ़ंक्शन ने माउसऑब्जेक्ट के संदर्भ में पारित किया है। मैं एओपी (या सभी भविष्य के उदाहरणों को क्लास पर प्रोटोटाइप बदलकर केवल उदाहरणों में बदल सकता हूं)।

कुछ इस तरह:

var m = new MouseObject();
m.after("onClick", function () {...}); //you need to add .after to your class or use an apply pattern from library code

यह केवल इस बात पर निर्भर करता है कि आप कैसे सोचते हैं कि इसका उपयोग किया जाएगा: कुछ उदाहरण, भविष्य के सभी उदाहरण (बंद होने तक) या सब कुछ

  1. एक "घटना कतार" का सुझाव दिया गया था। यह अधिक सक्रिय ऑब्जेक्ट पैटर्न की तरह है जहां आप ऑब्जेक्ट्स की एक सरणी और कार्य प्रबंधन के लिए एक कतार प्रबंधक का उपयोग करते हैं। यह लागू करने के लिए सबसे आसान है, लेकिन कई कमियां हैं जहां कतार "जाम कर सकते हैं" और अब प्रक्रिया नहीं है मैंने इस प्रकार के प्रबंधन के लिए एक पुस्तकालय लिखा था जिसे मैंने एक iPhone ऐप के आधार पर प्रोटो-क्यू (http://code.google.com/p/proto-q/) नाम दिया था। यह मेरे लिए बहुत अच्छा काम करता है, लेकिन यह सभी के आवेदन के लिए नहीं है।



Related