स्पष्ट वादा निर्माण एंटीपैटर्न क्या है और मैं इसे कैसे बचा सकता हूं?

Question

मैं कोड लिख रहा था जो कुछ ऐसा दिखता है:

function getStuffDone(param) {           | function getStuffDone(param) {
    var d = Q.defer(); /* or $q.defer */ |     return new Promise(function(resolve, reject) {
    // or = new $.Deferred() etc.        |     // using a promise constructor
    myPromiseFn(param+1)                 |         myPromiseFn(param+1)
    .then(function(val) { /* or .done */ |         .then(function(val) {
        d.resolve(val);                  |             resolve(val);
    }).catch(function(err) { /* .fail */ |         }).catch(function(err) {
        d.reject(err);                   |             reject(err);
    });                                  |         });
    return d.promise; /* or promise() */ |     });
}                                        | }

किसी ने मुझे बताया कि इसे क्रमशः " आस्थगित एंटीपैटर्न " या " Promiseकंस्ट्रक्टर एंटीपैटर्न " कहा जाता है, इस कोड के बारे में क्या बुरा है और इसे एंटीपैटर्न क्यों कहा जाता है ?

Answer 1

आस्थगित antipattern (अब स्पष्ट निर्माणाधीन antipattern) द्वारा गढ़ा Esailija एक आम antipattern लोग हैं, जो नए वादों बनाने के लिए कर रहे हैं, मैं इसे अपने आप जब मैं पहली बार इस्तेमाल किया वादे कर दिया है। उपरोक्त कोड के साथ समस्या यह है कि श्रृंखला का वादा करने वाले तथ्य का उपयोग करने में विफल रहता है।

वादे के साथ चेन .thenकर सकते हैं और आप सीधे वादे वापस कर सकते हैं। आपके कोड को getStuffDoneइस रूप में फिर से लिखा जा सकता है:

function getStuffDone(param){
    return myPromiseFn(param+1); // much nicer, right?
}

वादे सभी अतुल्यकालिक कोड को अधिक पठनीय बनाने के बारे में हैं और उस तथ्य को छिपाए बिना तुल्यकालिक कोड की तरह व्यवहार करते हैं। वादे एक समय ऑपरेशन के मूल्य पर एक अमूर्तता का प्रतिनिधित्व करते हैं, वे एक प्रोग्रामिंग भाषा में एक बयान या अभिव्यक्ति की धारणा को सार करते हैं।

जब आप एपीआई को वादों में परिवर्तित कर रहे हों, तब आप केवल आस्थगित वस्तुओं का उपयोग करें और यह स्वचालित रूप से नहीं कर सकते हैं, या जब आप एकत्रीकरण कार्य लिख रहे हैं जो इस तरह से आसान होते हैं।

कोटिंग एस्सलाइजा:

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

Answer 2

इसके साथ गलत क्या है?

लेकिन पैटर्न काम करता है!

तुम भाग्यशाली हो। दुर्भाग्य से, यह शायद नहीं है, जैसा कि आप की संभावना है कि कुछ किनारे के मामले को भूल गए। मैंने देखी गई घटनाओं में से आधे से अधिक में, लेखक त्रुटि हैंडलर की देखभाल करना भूल गया है:

return new Promise(function(resolve) {
    getOtherPromise().then(function(result) {
        resolve(result.property.example);
    });
})

यदि दूसरा वादा खारिज कर दिया जाता है, तो यह नए वादे (जहां इसे संभाला जाएगा) के प्रचार के बजाय किसी का ध्यान नहीं जाएगा - और नया वादा हमेशा के लिए लंबित रहता है, जो लीक को प्रेरित कर सकता है।

मामले में ऐसा ही होता है कि आपका कॉलबैक कोड एक त्रुटि का कारण बनता है - जैसे कि जब resultएक propertyऔर एक अपवाद नहीं होता है तो उसे फेंक दिया जाता है। यह बिना सोचे-समझे चल जाएगा और नए वादे को अनसुलझा छोड़ देगा।

इसके विपरीत, उपयोग करना .then()इन दोनों परिदृश्यों का स्वचालित रूप से ध्यान रखता है, और त्रुटि होने पर नए वादे को अस्वीकार करता है:

 return getOtherPromise().then(function(result) {
     return result.property.example;
 })

आस्थगित एंटीपैटर्न न केवल बोझिल है, बल्कि त्रुटि-प्रवण भी है । .then()चेनिंग के लिए उपयोग करना अधिक सुरक्षित है।

लेकिन मैंने सब कुछ संभाला है!

वास्तव में? अच्छा। हालांकि, यह बहुत विस्तृत और प्रचुर होगा, खासकर यदि आप एक वादा पुस्तकालय का उपयोग करते हैं जो रद्द करने या संदेश पास करने जैसी अन्य सुविधाओं का समर्थन करता है। या शायद यह भविष्य में होगा, या आप अपने पुस्तकालय को एक बेहतर के खिलाफ स्वैप करना चाहते हैं? आप उसके लिए अपने कोड को फिर से लिखना नहीं चाहेंगे।

पुस्तकालयों के तरीके ( then) केवल सभी सुविधाओं का मूल रूप से समर्थन नहीं करते हैं, उनके स्थान पर कुछ अनुकूलन भी हो सकते हैं। उनका उपयोग करने से संभवतः आपके कोड में तेज़ी आएगी, या कम से कम लाइब्रेरी के भविष्य के संशोधनों द्वारा अनुकूलित होने की अनुमति होगी।

मैं इससे कैसे बचूं?

इसलिए जब भी आप खुद को मैन्युअल रूप से एक Promiseया Deferredपहले से मौजूद वादों को शामिल करते हुए पाते हैं, तो पहले पुस्तकालय एपीआई की जांच करें । Deferred antipattern अक्सर उन लोगों द्वारा लागू किया जाता है जो वादे देखते हैं [केवल] एक पर्यवेक्षक पैटर्न के रूप में - लेकिन वादे कॉलबैक से अधिक हैं : उन्हें रचना योग्य माना जाता है। हर सभ्य पुस्तकालय में हर विचारशील तरीके से वादों की रचना के लिए बहुत सारे आसान-से-उपयोग के कार्य हैं, उन सभी निम्न-स्तरीय सामानों की देखभाल करना, जिनसे आप निपटना नहीं चाहते हैं।

यदि आपको एक नए तरीके से कुछ वादों की रचना करने की आवश्यकता है जो एक मौजूदा सहायक फ़ंक्शन द्वारा समर्थित नहीं है, तो अपरिहार्य डिफ्रेड्स के साथ अपना फ़ंक्शन लिखना आपका अंतिम विकल्प होना चाहिए। एक और अधिक उपयोगी पुस्तकालय में जाने पर विचार करें, और / या अपने वर्तमान पुस्तकालय के खिलाफ बग दर्ज करें। इसके अनुरक्षक को मौजूदा कार्यों से रचना को प्राप्त करने में सक्षम होना चाहिए, आपके लिए एक नया सहायक फ़ंक्शन लागू करना चाहिए और / या उन किनारे मामलों की पहचान करने में मदद करना चाहिए जिन्हें संभालने की आवश्यकता है।