2009-05-04 14 views
5

यदि मैं पूरी तरह गलत नहीं हूं, तो जावास्क्रिप्ट में प्रत्येक ढांचे/पुस्तकालय/दृष्टिकोण आज कक्षा आधारित ओओपी शैली विरासत की नकल करने के लिए आता है। ऐसा लगता है कि कक्षाएं आधारित ओओपी विरासत को समझने के लिए लोग बहुत आसान हैं और अधिकांश प्रोग्रामर ओओपी को जानते हैं।जावास्क्रिप्ट में कक्षा आधारित ओओपी शैली विरासत का उपयोग क्यों करें?

मेरे अनुभव में मुझे इस राय के लिए सबूत नहीं मिलते हैं। मुझे लगता है कि जावास्क्रिप्ट प्रोटोटाइप विरासत सिर्फ ठीक है (और मुझे उस भाषा की तुलना में किसी अन्य प्रतिमान को मजबूर करने के लिए उपयोगिता पर संदेह है)। मैं जिन अधिकांश डेवलपर्स से मिलता हूं वे शास्त्रीय ओओपी में भी अच्छे नहीं हैं। तो प्रोटोटाइप विरासत पर शास्त्रीय ओओपी शैली विरासत का चयन करने के कारण क्या हैं?

+0

बहस यहाँ खत्म नहीं होता:

Btw, मैं लोकप्रिय विरासत पैटर्न यहाँ के सबसे का उदाहरण है? मैं एक दिलचस्प कागज सारांशित करता हूं। संक्षेप में, कक्षा-आधारित विश्वव्यापी प्रोटोटाइप में से एक की तुलना में अधिक त्रुटिपूर्ण है।तो, हमें सावधान रहना होगा। सारांश यहां दिया गया है: http://carnotaurus.tumblr.com/post/3248631891/class-based-javascript-or-not – CarneyCode

+0

आपने जो असली सवाल पूछ रहा था उसे उजागर किया :) बस आज अपना काम देखा। इस पर ध्यान दिलाने के लिए धन्यवाद। –

उत्तर

6

मुझे लगता है कि उत्तर आपके प्रश्न में है - अधिकांश प्रोग्रामर प्रोटोटाइप-आधारित की तुलना में कक्षा-आधारित ओओपी से कहीं ज्यादा परिचित हैं।

असल में मैं कहूंगा कि बहुमत यह नहीं मानता कि बहुमत यह नहीं मानता कि आपके पास कक्षाओं के बिना वस्तुएं हो सकती हैं।

+0

मेरे सामने आने वाले अधिकांश डेवलपर्स प्रोटोटाइप और ओओपी में बहुत अच्छे नहीं हैं। तो यह सिर्फ एक मामला होगा जो आप पहले सीखते हैं। और इससे भी मैं इसे एक और भाषा बनाने की कोशिश नहीं करूँगा जैसा कि यह है। मैं मानता हूं कि ज्यादातर लोग कक्षाओं के लिए वस्तुओं की आवश्यकता देखते हैं। लेकिन जावास्क्रिप्ट में भी है। नाम केवल differen हैं;) –

0

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

अब, ओओपी के साथ एहसास करना बहुत आसान है - खासकर क्योंकि प्रोग्रामर ओओपी अवधारणाओं से परिचित हैं।

+0

यह वही है जो मुझे समझ में नहीं आता है। निश्चित रूप से यदि आप सभी सहमत हैं कि अधिकांश डेवलपर्स ओओपी से परिचित हैं, तो मैं इसे लेता हूं। लेकिन ओओपी प्रोटोटाइप दृष्टिकोण से ज्यादा शक्तिशाली बनाता है। खैर, मैं खुद को "सुपर" अतिवृद्धि प्राप्त करता हूं। तो यह और क्या है? –

0

एक कारण यह हो सकता है कि आपका सर्वर पक्ष ओओ (एएसपी.नेट, जावा इत्यादि) होने की संभावना है, इसलिए क्लाइंट पर समान प्रतिमान में विचार करना आसान है। आवश्यक नहीं बेहतर, लेकिन आसान है।

+0

अच्छा, नहीं। आप अपने डेटा को कुछ मध्यवर्ती प्रारूप में serialize/marshall। कुछ अलग में अनारक्षित करना आईएमएचओ कोई समस्या नहीं है। यहां तक ​​कि यदि आपके पास ऐसी चीजें हैं जो क्लाइंट और सर्वर पर समान व्यवहार करनी चाहिए और ये शायद ही कभी हैं। –

+0

@ नोर्बर्ट: सिर्फ इसलिए कि यह व्यावहारिक नहीं है इसका मतलब यह नहीं है कि इसका प्रयास नहीं किया जाएगा। यह भी देखें: वेबफॉर्म, जीडब्ल्यूटी ... – Shog9

6

ध्यान दें कि भले ही आप प्रोटोटाइप-आधारित ओओपी के लिए बहस कर रहे हों, आप इसे 'प्रोटोटाइप' और क्लास-आधारित ओओपी 'ओओपी' कहते हैं। इसलिए, आप स्वयं इस पूर्वाग्रह से पीड़ित हैं, ओओपी => कक्षाएं, प्रोटोटाइप => कुछ और सोच रहे हैं।

और चूंकि अधिकांश लोग सोचते हैं कि ओओपी सही है समस्या से कोई फर्क नहीं पड़ता, तो प्रोटोटाइप कम होना चाहिए।

  1. एक बुरा परिभाषा: "OOP => वर्ग"
    • प्रचार: "यह OOP होना चाहिए, या आप योग्य नहीं हो

      हां, तो आपके सवाल का जवाब देना है, यह दो कारकों है "

के बाद आप अभी भी पहले से घिरा रहे हैं, आप को समझाने के लिए कि प्रोटोटाइप दूसरे का एक अपवाद नहीं हैं की कोशिश करो। उन्हें सही करना बहुत आसान है:

  1. वस्तुओं को करने के कई तरीके हैं, कक्षाएं स्थिर भाषाओं के लिए सबसे आसान हैं। अधिकांश लोगों को स्थिर भाषाओं के साथ प्रोग्राम करना सिखाया जाता है, और उनमें से अधिकतर किसी भी भाषा का उपयोग करने की कोशिश करते हैं जैसे कि उन्होंने पहले सीखा।

    • प्रोग्रामिंग समाधान की संरचना करने के कई तरीके हैं, ओओपी कुछ और दूसरों पर लुभावनी हैं।
+0

मुझे वह नहीं मिलता है जो आप कहना चाहते हैं। मैं सिर्फ अपने इरादों के बारे में आपकी धारणाओं से सहमत नहीं हो सकता। –

+0

बीटीडब्ल्यू। मैंने टेक्स्ट संपादित किया है, इसलिए उम्मीद है कि –

+2

गलत व्याख्या करने के लिए यह कम आसान है कि मैं क्या कह रहा हूं कि प्रोटोटाइप आधारित विरासत कक्षा आधारित विरासत के रूप में ओओपी के समान है। ओओपी को कॉल करना और दूसरा यह विचार इस बात को मजबूत नहीं करता है कि प्रोटोटाइप 'पर्याप्त नहीं' हैं, भले ही आप उस पर विश्वास न करें, आपकी पसंद की पसंद आपके खिलाफ काम करती है। – Javier

1

मैं बहस चाहते हैं कि स्वयं भाषा शास्त्रीय मानसिकता के साथ यह 'नई' की पसंद है एक कीवर्ड के रूप में और "कंस्ट्रक्टर्स" भाषा विनिर्देश में की तरह अवधारणाओं शुरू करने से लोगों को बना। एक तरह से यह सीमित है - मानसिकता में परिवर्तन की कल्पना करें अगर इसके बजाय हमारे पास क्लोन कीवर्ड था, और लक्षणों की अवधारणा एला एसईएलएफ।

+0

यह एक अच्छा मुद्दा है। मुझे यकीन नहीं है कि क्या एसईएलएफ जावास्क्रिप्ट के समान नहीं होगा। खैर, स्वयं में आपको क्लोन करना होगा, लेकिन आपको क्या कहना है कि "नया" नहीं होगा जो "क्लोन" + "रीसेट वैल्यू" को फिर से इकट्ठा करेगा? और गुणों को तब कई विरासतों के रूप में माना जाएगा जिन्हें सी ++ से जाना जाता है। क्या आप सहमत नहीं हैं? –

+0

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

+0

मुझे पता है कि जावास्क्रिप्ट का इतिहास दुखद है। उन्हें रिहा करने के लिए धकेल दिया गया था, यह जावा की तरह दिखता है और यहां तक ​​कि उस नाम का नाम भी है। सभी विपणन कुछ हद तक नीचे लाया। –

4

मुझे लगता है के रूप में यदि आप पहले से ही अपने प्रश्न का उत्तर जानते हैं, क्योंकि आप इसे का एक हिस्सा कहा गया है कि जब आप ने कहा कि लोगों को सोच वर्ग आधारित OOP विरासत दूर करने के लिए आसान है होने लगते हैं इस बात के लिए

कारण समझें और अधिकांश प्रोग्रामर ओओपी को जानते हैं।

किसी भी समस्या का सामना करने के लिए न तो प्रतिमान दूसरे से अधिक सही है। मेरा मानना ​​है कि मुख्य कारण यह है कि इन दिनों जावा के माध्यम से हर किसी को ओओपी सिखाया जाता है। तो जब लोग ओओपी का सामना करते हैं तो वे "ओह कक्षाएं" सोचते हैं क्योंकि वे यही परिचित हैं। और जब भी वे किसी समस्या को हल करना चाहते हैं, तो वे संभवतः उन चीज़ों का उपयोग करेंगे जो वे जानते हैं।

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

एक निश्चित स्तर पर तथ्य यह है कि हर कोई जावास्क्रिप्ट में कक्षा आधारित ओओपी लागू करने की कोशिश कर रहा है एक शैक्षिक मुद्दा है। एक और स्तर पर यह एक मनोवैज्ञानिक है।

3

लंबे समय तक मैंने प्रोटोटाइप-आधारित ओओपी को कक्षा-आधारित ओओपी के कमजोर, बुरे और गलत संस्करण के रूप में माना। फिर, मेरे सिर में लीक की गई बड़ी मात्रा में जानकारी के बाद, अब मैं ओओपी को अधिक अमूर्त तरीके से समझता हूं, और सामान्य रूप से स्वीकार्य दोनों तरीकों को ढूंढता हूं।

3

तो प्रोटोटाइप विरासत पर शास्त्रीय ओओपी शैली विरासत चुनने के कारण क्या हैं? असल में, मेरा मानना ​​है कि कुछ ढांचे दृष्टिकोणों के संयोजन के "प्रकार" हैं। उदाहरण के लिए परजीवी संयोजन विरासत पैटर्न ले लो। यही वह है जो YAHOO.lang.extend कर रहा है।

यह प्रोटोटाइप और कन्स्ट्रक्टर चोरी के उत्तराधिकारी के लिए प्रोटोटाइप विरासत और एक सहायक कार्य का उपयोग करता है। वाह, यह जटिल लगता है ... अच्छी तरह से हाँ यह है - यहाँ मेरी कार्यान्वयन और उदाहरण के लिए परीक्षण है:

// Prototypal Inheritance 
Object.prototype.inherit = function(p) { 
    NewObj = function(){}; 
    NewObj.prototype = p; 
    return new NewObj(); 
}; 

// Paraphrasing of Nicholas Zakas's Prototype Inheritance helper 
function inheritPrototype(subType, superType) { 
    var prototype = Object.inherit(superType.prototype); 
    prototype.constructor = subType; 
    subType.prototype = prototype; 
}; 
function SubType(name, age) { 
    Parent.call(this, name); 
    this.age = age;  
}; 
inheritPrototype(SubType, Parent); 
SubType.prototype.getAge = function() { 
    return this.age; 
}; 

मैं इस कोड के लिए एक परीक्षण है:

describe 'Parisitic Combination Inheritance' 
it 'should use inheritPrototype (to call parent constructor once) and still work as expected' 
    sub = new SubType("Nicholas Zakas", 29) 
    sub.toString().should.match /.*Nicholas Zakas/ 
    sub.getAge().should.eql 29 
    charlie = new SubType("Charlie Brown", 69) 
    charlie.arr.should.eql([1,2,3]) 
    charlie.arr.push(999) 
    charlie.arr.should.eql([1,2,3,999]) 
    sub.arr.should.eql([1,2,3]) 
    sub.should.be_an_instance_of SubType 
    charlie.should.be_an_instance_of SubType 
    (sub instanceof SubType).should.eql true 
    (sub instanceof Parent).should.eql true 
end 
    end 

और निश्चित रूप से, अगर आप ' मेरे साहित्यों पर ध्यान दे रहे हैं जो आप देखते हैं: निकोलस जाकास, जिस लड़के से मुझे यह मिला;) इस के लिए बड़ी जीत: उदाहरण के काम (कुछ सौदा कुछ कहते हैं और मैं सहमत हूं); उदाहरण संदर्भ प्रकारों जैसे राज्यों को एरेज़ (एक biggie!) पर साझा नहीं करते हैं; अभिभावक कन्स्ट्रक्टर केवल एक बार बुलाया जाता है (एक बड़ी!)। My TDD JS Examples

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