जावा में क्या स्टाइल बेहतर (इंस्टेंस वेरिएबल बनाम रिटर्न वैल्यू) है

Question

जब मैं अपनी कक्षाओं में कुछ तरीकों से सामान्य डेटा का उपयोग करने की आवश्यकता होती है, तो मुझे इन दो तरीकों में से एक का उपयोग करने का निर्णय लेने के लिए अक्सर संघर्ष करते हुए पाया जाता है। इससे बेहतर विकल्प क्या होगा?

इस विकल्प में, मैं अतिरिक्त चर घोषित करने की आवश्यकता से बचने के लिए एक आवृत्ति चर बना सकता हूं, और साथ ही परिभाषित करने के विधि मापदंडों से भी बच सकता हूं, लेकिन यह स्पष्ट नहीं हो सकता है कि उन चर को तत्काल कहां से संशोधित / संशोधित किया जा रहा है:

public class MyClass {
    private int var1;

    MyClass(){
        doSomething();
        doSomethingElse();
        doMoreStuff();
    }

    private void doSomething(){
        var1 = 2;
    }

    private void doSomethingElse(){
        int var2 = var1 + 1;
    }

    private void doMoreStuff(){
        int var3 = var1 - 1;
    }
}

या सिर्फ स्थानीय चर को तात्कालिक करना और उन्हें तर्क के रूप में पारित करना?

public class MyClass {  
    MyClass(){
        int var1 = doSomething();
        doSomethingElse(var1);
        doMoreStuff(var1);
    }

    private int doSomething(){
        int var = 2;
        return var;
    }

    private void doSomethingElse(int var){
        int var2 = var + 1;
    }

    private void doMoreStuff(int var){
        int var3 = var - 1;
    }
}

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

Comments

रेलेटाड (डुप्लिकेट?): प्रोग्रामर.स्टैकएक्सचेंज

— मार्टिन बा

मुझे नहीं लगता कि किसी ने अभी तक बताया है कि उदाहरण चर में मध्यवर्ती परिणाम डालना इन चरों के लिए थ्रेड्स के बीच विवाद की संभावना के कारण संगामिति को और अधिक कठिन बना सकता है।

— श्रीधाम

Answer 1

मुझे आश्चर्य है कि यह अभी तक उल्लेख नहीं किया गया है ...

यह निर्भर करता है कि var1क्या वास्तव में आपकी वस्तु की स्थिति का हिस्सा है ।

आप मानते हैं कि ये दोनों दृष्टिकोण सही हैं और यह केवल शैली की बात है। तुम गलत हो।

यह पूरी तरह से कैसे ठीक से मॉडल के बारे में है।

इसी तरह, privateउदाहरण के तरीके आपकी वस्तु की स्थिति को बदलने के लिए मौजूद हैं । अगर ऐसा नहीं है तो आपका तरीका क्या है, यह होना चाहिए private static।

Comments

@ मुचाहो: transientइससे कोई लेना-देना नहीं है, क्योंकि लगातार स्थिति के transientबारे में है, जैसा कि ऑब्जेक्ट के कुछ हिस्सों में किया जाता है जब आप ऑब्जेक्ट को सीरियलाइज़ करते हैं। उदाहरण के लिए, एक ArrayList का बैकिंग स्टोर भले ही ArrayList की स्थिति के लिए अत्यंत महत्वपूर्ण है, क्योंकि जब आप एक ArrayList को क्रमबद्ध कर रहे होते हैं, तो आप केवल बैकिंग स्टोर के उस भाग को बचाना चाहते हैं जो वास्तविकrayList तत्व रखता है, न कि मुक्त स्थान। अंत में आगे तत्व परिवर्धन के लिए आरक्षित है। transient

— user2357112

उत्तर में जोड़ना - यदि var1कुछ तरीकों के लिए आवश्यक है, लेकिन राज्य के भाग के लिए नहीं MyClass, तो इसे लगाने का समय हो सकता है var1और उन विधियों को किसी अन्य वर्ग में उपयोग करने के लिए MyClass।

— माइक पार्टरिज

@CandiedOrange हम यहां सही मॉडलिंग के बारे में बात कर रहे हैं। जब हम कहते हैं "ऑब्जेक्ट का राज्य," हम कोड में शाब्दिक टुकड़ों के बारे में बात नहीं कर रहे हैं। हम राज्य की एक वैचारिक धारणा पर चर्चा कर रहे हैं , अवधारणाओं को ठीक से मॉडल करने के लिए वस्तु की स्थिति क्या होनी चाहिए । "उपयोगी जीवनकाल" उस में सबसे बड़ा निर्णायक कारक है।

— jpmc26

@CandiedOrange अगला और पिछला स्पष्ट रूप से सार्वजनिक तरीके हैं। यदि var1 का मान केवल निजी विधियों के अनुक्रम में प्रासंगिक है, तो यह स्पष्ट रूप से ऑब्जेक्ट की स्थायी स्थिति का हिस्सा नहीं है और इस तरह से तर्क के रूप में पारित किया जाना चाहिए।

— तैमूर

@CandiedOrange आपने दो टिप्पणियों के बाद स्पष्ट किया कि आपका क्या मतलब है। मैं कह रहा हूं कि आप पहले उत्तर में आसानी से हो सकते हैं। इसके अलावा, हाँ, मैं भूल गया कि वहाँ सिर्फ वस्तु से अधिक है; मैं मानता हूँ कि कभी-कभी निजी उदाहरण के तरीकों का एक उद्देश्य होता है। मैं अभी दिमाग में नहीं ला सका। संपादित करें: मुझे एहसास हुआ कि आप वास्तव में, मेरे जवाब देने वाले पहले व्यक्ति नहीं थे। मेरी गलती। मैं इस उलझन में था कि क्यों एक उत्तर एक शाप, एक-वाक्य, गैर-उत्तर था, जबकि अगला वास्तव में समझाया गया था।

— निधि मोनिका का मुकदमा

Answer 2

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

Answer 3

आपको अपने चरों के दायरे को यथासंभव कम करना चाहिए (और उचित)। न केवल तरीकों में, बल्कि आम तौर पर।

आपके प्रश्न के लिए इसका अर्थ है कि यह निर्भर करता है कि चर वस्तु की स्थिति का हिस्सा है या नहीं। यदि हाँ, तो उस दायरे में इसका उपयोग करना ठीक है, अर्थात पूरी वस्तु। इस मामले में पहले विकल्प के साथ जाएं। यदि नहीं, तो दूसरे विकल्प के साथ जाएं क्योंकि यह चर की दृश्यता कम कर देता है और इस प्रकार समग्र जटिलता।

Answer 4

जावा में क्या स्टाइल बेहतर (इंस्टेंस वेरिएबल बनाम रिटर्न वैल्यू) है

एक और शैली है - एक संदर्भ / स्थिति का उपयोग करें।

public static class MyClass {
    // Hold my state from one call to the next.
    public static final class State {
        int var1;
    }

    MyClass() {
        State state = new State();
        doSomething(state);
        doSomethingElse(state);
        doMoreStuff(state);
    }

    private void doSomething(State state) {
        state.var1 = 2;
    }

    private void doSomethingElse(State state) {
        int var2 = state.var1 + 1;
    }

    private void doMoreStuff(State state) {
        int var3 = state.var1 - 1;
    }
}

इस दृष्टिकोण के कई लाभ हैं। राज्य की वस्तुएं उदाहरण के लिए वस्तु के स्वतंत्र रूप से बदल सकती हैं, जिससे भविष्य के लिए बहुत अधिक जगह हो सकती है।

यह एक पैटर्न है जो एक वितरित / सर्वर सिस्टम में भी अच्छी तरह से काम करता है जहां कुछ विवरणों को कॉल के दौरान संरक्षित किया जाना चाहिए। आप stateऑब्जेक्ट में उपयोगकर्ता विवरण, डेटाबेस कनेक्शन आदि को स्टोर कर सकते हैं ।

Answer 5

यह दुष्प्रभावों के बारे में है।

यह पूछे जाने पर कि क्या var1राज्य का हिस्सा इस प्रश्न के बिंदु को याद करता है। अगर निश्चित रूप से var1जारी रहना चाहिए, तो यह एक उदाहरण होना चाहिए। या तो काम करने के लिए दृष्टिकोण किया जा सकता है कि क्या दृढ़ता की आवश्यकता है या नहीं।

साइड इफेक्ट दृष्टिकोण

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

आप एक चर को इसके दायरे से बाहर जाने दे रहे हैं क्योंकि इसका उपयोग दो अलग-अलग निजी स्कोप में किया जाता है। इसलिए नहीं कि आप इसे अपने दायरे में रख रहे हैं। यह भ्रामक हो सकता है। "ग्लोबल्स बुराई हैं!" भ्रमित करने का स्तर। यह काम कर सकता है, लेकिन यह सिर्फ अच्छे पैमाने पर नहीं होगा। यह केवल छोटे में काम करता है। कोई बड़ी वस्तु नहीं। कोई लंबी वंशानुक्रम श्रृंखला नहीं। एक यो यो प्रभाव का कारण नहीं है ।

कार्यात्मक दृष्टिकोण

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

राज्य का हिस्सा या नहीं, आप अभी भी दृष्टिकोण का उपयोग कर सकते हैं।

इन उदाहरणों में 'var1' इतना एनकैप्सुलेटेड है कि आपके डिबगर के अलावा यह मौजूद नहीं है। मैं अनुमान लगा रहा हूं कि आपने जानबूझकर किया क्योंकि आप हमें पूर्वाग्रह नहीं करना चाहते। सौभाग्य से मुझे परवाह नहीं है।

साइड इफेक्ट का खतरा

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

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

साइड इफेक्ट्स का उल्टा

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

कार्यात्मक निजी तरीकों का नकारात्मक पक्ष

कार्यात्मक दृष्टिकोण कुछ निर्भरता को स्पष्ट करता है। जब तक आपकी शुद्ध कार्यात्मक भाषा में यह छिपी निर्भरता को खारिज नहीं कर सकता। आपको पता नहीं है, सिर्फ एक तरीके के हस्ताक्षर को देखते हुए, कि यह बाकी कोड में आपसे कोई साइड इफ़ेक्ट नहीं छुपा रहा है। तुम बस नहीं।

सशर्त पोस्ट करें

यदि आप, और टीम के बाकी सभी लोग, टिप्पणियों में साइड इफेक्ट्स (पूर्व / पोस्ट की स्थिति) का मज़बूती से दस्तावेज़ करते हैं, तो कार्यात्मक दृष्टिकोण से लाभ बहुत कम है। हाँ, मुझे पता है, पर सपना।

निष्कर्ष

व्यक्तिगत रूप से मैं किसी भी मामले में कार्यात्मक निजी तरीकों की ओर जाता हूं अगर मैं कर सकता हूं, लेकिन ईमानदारी से यह ज्यादातर है क्योंकि उन पूर्व / पोस्ट सशर्त साइड इफेक्ट टिप्पणी कंपाइलर त्रुटियों का कारण नहीं बनती हैं जब वे पुरानी हो जाती हैं या जब तरीकों को आदेश से बाहर कहा जाता है। जब तक मुझे वास्तव में साइड इफेक्ट्स के लचीलेपन की आवश्यकता होती है, तब तक मैं सिर्फ इतना जानता हूं कि चीजें काम करती हैं।

Comments

"कुछ उदाहरण चर केवल कॉल करने के लिए निजी तरीकों के बीच संवाद करने के लिए उपयोग किए जाते हैं।" यह एक कोड गंध है। जब उदाहरण चर का उपयोग इस तरह से किया जाता है, तो यह एक संकेत है कि कक्षा बहुत बड़ी है। उस चर और विधियों को एक नए वर्ग में निकालें।

— केविन क्लाइन

यह वास्तव में कोई मतलब नहीं है। जबकि ओपी कार्यात्मक प्रतिमान में कोड लिख सकता है (और यह आमतौर पर एक अच्छी बात होगी), यह स्पष्ट रूप से सवाल का संदर्भ नहीं है। ओपी को यह बताने की कोशिश की जा रही है कि वे वस्तु की स्थिति को बदलते हुए प्रतिमानों को संग्रहीत करने से बच सकते हैं जो वास्तव में प्रासंगिक नहीं है ...

— jpmc26

@ ओपेकलाइन के उदाहरण में केवल एक उदाहरण चर और 3 विधियाँ हैं। अनिवार्य रूप से, यह पहले से ही एक नए वर्ग में निकाला गया है। ऐसा नहीं है कि उदाहरण कुछ उपयोगी है। कक्षा के आकार का इससे कोई लेना-देना नहीं है कि आपके निजी सहायक तरीके एक-दूसरे से कैसे संवाद करते हैं।

— मैजिकविंडो

@ jpmc26 ओपी ने पहले ही दिखा दिया है कि वे var1प्रतिमानों को बदलकर राज्य चर के रूप में भंडारण से बच सकते हैं । क्लास स्कोप सिर्फ वह जगह नहीं है जहां राज्य संग्रहीत है। यह एक घेरने की गुंजाइश भी है। इसका मतलब है कि कक्षा स्तर पर एक चर रखने के लिए दो संभावित प्रेरणाएं हैं। आप केवल संलग्न क्षेत्र के लिए यह कर दावा कर सकते हैं और नहीं राज्य बुराई है, लेकिन मैं कहना है कि यह साथ एक व्यापार है arity जो भी बुराई है। मुझे यह पता है क्योंकि मुझे कोड को बनाए रखना है जो ऐसा करता है। कुछ अच्छा किया गया था। कुछ एक बुरा सपना था। दोनों के बीच की रेखा नहीं है। यह पठनीयता है।

— मैजिकविंडो

राज्य शासन पठनीयता को बढ़ाता है: 1) संचालन के अंतरिम परिणाम राज्य 2 की तरह दिखने से बचें) तरीकों की निर्भरता को छिपाने से बचें। यदि किसी विधि की उच्चता है, तो यह या तो अनियमित रूप से होती है और वास्तव में उस पद्धति की जटिलता का प्रतिनिधित्व करती है या वर्तमान डिजाइन में अनावश्यक जटिलता है।

— श्रीधाम

Answer 6

पहला संस्करण मेरे लिए गैर-सहज और संभावित रूप से खतरनाक लगता है (किसी भी कारण से किसी को भी अपनी निजी पद्धति को सार्वजनिक करने के लिए कल्पना करें)।

मैं कक्षा निर्माण पर आपके चरों को तुरंत या तो उन्हें तर्क के रूप में पास कर दूंगा। उत्तरार्द्ध आपको कार्यात्मक मुहावरों का उपयोग करने और युक्त वस्तु की स्थिति पर भरोसा न करने का विकल्प देता है।

Answer 7

ऑब्जेक्ट स्टेट के बारे में बात करते हुए पहले से ही उत्तर हैं और जब दूसरी विधि पसंद की जाती है। मैं सिर्फ पहले पैटर्न के लिए एक सामान्य उपयोग के मामले को जोड़ना चाहता हूं।

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

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

Answer 8

आइए एक उदाहरण का प्रयास करें जो कुछ करता है। मुझे माफ कर दो क्योंकि यह जावास्क्रिप्ट है जावा नहीं। बिंदु समान होना चाहिए।

यात्रा https://blockly-games.appspot.com/pond-duck?lang=en , जावास्क्रिप्ट टैब क्लिक करें और इस पेस्ट:

hunt = lock(-90,1), 
heading = -135;

while(true) {
  hunt()  
  heading += 2
  swim(heading,30)
}

function lock(direction, width) {
  var dir = direction
  var wid = width
  var dis = 10000

  //hunt
  return function() {
    //randomize() //Calling this here makes the state of dir meaningless
    scanLock()
    adjustWid()
    if (isSpotted()) {
      if (inRange()) {
        if (wid <= 4) {
          cannon(dir, dis)
        }
      }
    } else {
      if (!left()) {
        right()
      }
    }
  }

  function scanLock() {
    dis = scan(dir, wid);
  }

  function adjustWid() {
    if (inRange()) {
      if (wid > 1)
        wid /= 2;
    } else {
      if (wid < 16) {
        wid *= 2; 
      }
    }
  }

  function isSpotted() {
    return dis < 1000;
  }

  function left() {
    dir += wid;
    scanLock();
    return isSpotted();
  }

  function right() {
    dir -= wid*2;
    scanLock();
    return isSpotted()
  }

  function inRange() {
    return dis < 70;
  }

  function randomize() {
    dir = Math.random() * 360
  }
}

आपको ध्यान देना चाहिए कि dir, widऔर disबहुत पास नहीं हो रहे हैं। आपको यह भी ध्यान देना चाहिए कि फ़ंक्शन का कोड जो lock()रिटर्न करता है वह छद्म कोड की तरह दिखता है। वैसे यह वास्तविक कोड है। फिर भी इसे पढ़ना बहुत आसान है। हम पासिंग और असाइनिंग जोड़ सकते हैं लेकिन यह अव्यवस्था जोड़ देगा जिसे आपने छद्म कोड में कभी नहीं देखा होगा।

यदि आप यह तर्क देना चाहते हैं कि असाइन नहीं करना और पास करना ठीक है क्योंकि वे तीन संस्करण लगातार स्थिति हैं तो एक रीडिज़ाइन पर विचार करें जो dirहर लूप को एक यादृच्छिक मान प्रदान करता है। अब लगातार नहीं है, यह है?

ज़रूर, अब हम dirदायरे में नीचे गिर सकते हैं, लेकिन हमारे छद्म कोड और पासिंग के साथ कोड की तरह छद्म करने के लिए मजबूर किए बिना नहीं।

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

यह कहना नहीं है कि वे दुःस्वप्न की तरह स्पेगेटी में नहीं बदल सकते। लेकिन फिर, क्या नहीं कर सकता?

हैप्पी डक हंटिंग।

Comments

ओपी जो वर्णन करता है उसकी तुलना में आंतरिक / बाहरी कार्य एक अलग प्रतिमान हैं। - मैं मानता हूं कि बाहरी फ़ंक्शन कॉन्ट्रैक्ट में स्थानीय चरों के बीच होने वाला व्यापार आंतरिक कार्यों के लिए तर्कों को पारित करता है, यह एक वैरिएबल वैसा ही है जैसा कि एक क्लास कॉन्ट्रैक्ट पर निजी कार्यों के लिए दिया गया। हालाँकि यदि आप यह तुलना करते हैं कि ऑब्जेक्ट का जीवनकाल फ़ंक्शन के एक ही रन के अनुरूप होगा, तो बाहरी फ़ंक्शन में चर लगातार स्थिति का हिस्सा है।

— तैमूर

@ ओटायर ओपी एक सार्वजनिक निर्माणकर्ता के भीतर कहे जाने वाले निजी तरीकों का वर्णन करता है जो मुझे बाहरी के भीतर बहुत पसंद है। यदि आप हर बार किसी फ़ंक्शन में प्रवेश करते हैं तो राज्य वास्तव में 'लगातार' नहीं है। कभी-कभी राज्य का उपयोग एक साझा स्थान के तरीकों के रूप में किया जाता है और लिख सकते हैं। इसका मतलब यह नहीं है कि इसे बरकरार रखने की जरूरत है। तथ्य यह है कि यह वैसे भी कायम है कुछ भी निर्भर नहीं करता है।

— कैंडिड_ऑरेंज

यदि आप वस्तु के निपटान के लिए हर बार कदम बढ़ाते हैं तो भी यह लगातार बना रहता है।

— तैमूर

अच्छे अंक, लेकिन उन्हें जावास्क्रिप्ट में व्यक्त करना वास्तव में चर्चा को बाधित करता है। इसके अलावा, यदि आप जेएस सिंटैक्स को दूर करते हैं, तो आप संदर्भ ऑब्जेक्ट को (बाहरी फ़ंक्शन को बंद करने) के आसपास समाप्त हो जाते हैं

— fdreger

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

— कैंडिड_ओरेंज