गुण बनाम विधियाँ


135

त्वरित प्रश्न: आप गुणों का उपयोग करने का निर्णय कब लेते हैं (C # में) और आप विधियों का उपयोग करने का निर्णय कब लेते हैं?

हम इस बहस में व्यस्त हैं और कुछ ऐसे क्षेत्र हैं जहाँ यह बहस का विषय है कि हमें किसी संपत्ति या विधि का उपयोग करना चाहिए या नहीं। एक उदाहरण यह है:

public void SetLabel(string text)
{
    Label.Text = text;
}

उदाहरण में, Labelएक ASPX पृष्ठ पर एक नियंत्रण है। क्या कोई सिद्धांत है जो निर्णय (इस मामले में) को नियंत्रित कर सकता है कि क्या इसे एक विधि या संपत्ति बनाना है।

मैं उस उत्तर को स्वीकार करूंगा जो सबसे सामान्य और व्यापक है, लेकिन यह उस उदाहरण पर भी स्पर्श करता है जो मैंने दिया है।


2
: -1 इस प्रश्न पूछा गया है और जवाब से पहले stackoverflow.com/questions/164527/...
तत्व

विधि / क्षेत्र / संपत्ति के पेशेवरों और विपक्ष लंबी बहस उत्पन्न कर सकते हैं; गुणों के लिए कुछ सामान्य उपयोग: जब आप निजी / प्रोटेक्टेड फ़ील्ड चाहते हैं, लेकिन उसी समय आप उन्हें उजागर करना चाहते हैं। एक अन्य उपयोग में न केवल कथन हैं, बल्कि अभिव्यक्तियाँ भी हैं (यदि आपको पसंद है तो कार्रवाई भी) if()(एमएसडीएन के अनुसार)। लेकिन यह मुश्किल है क्योंकि उपयोगकर्ता हमेशा एक चर (संपत्ति) (यानी कोड उपलब्ध नहीं है) तक पहुँचने के पीछे प्रसंस्करण लागत के बारे में पता नहीं है और सख्ती के कारणों के लिए किसी को संपत्ति को बेंचमार्क करना होगा। ओह, और एक "बोनस" आप गुणों के साथ संकेत का उपयोग नहीं कर सकते।
मिरेज़मा

जवाबों:


145

कक्षा पुस्तकालयों को विकसित करने के लिए डिजाइन दिशानिर्देशों के गुणों और विधियों के बीच चयन से :

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


3
जबकि मैं इससे बहुत सहमत हूं, मुझे नहीं लगता कि साइड-इफेक्ट्स के बारे में सही है। उदाहरण के लिए, "रंग" अक्सर एक वस्तु का गुण होता है, और इसके स्पष्ट दुष्प्रभाव होते हैं (किसी वस्तु का रंग बदलना)। बदलते गुणों का वस्तु स्थिति बदलने का स्पष्ट दुष्प्रभाव है।
एरिक फनकेनबसच

46
मिस्टीयर मैन चेंजिंग कलर वांछित प्रभाव है साइड इफेक्ट नहीं। साइड इफेक्ट कुछ ऐसा है जो प्राथमिक कार्रवाई में इरादा नहीं है।
मुहम्मद हसन खान

2
@ मिस्टर मैन: निश्चित रूप से रंग बदलना कोई साइड इफ़ेक्ट नहीं है, मैं इस जवाब से पूरी तरह सहमत हूँ
अहमद ने कहा कि

2
"क्योंकि कम अनुभवी डेवलपर्स गुणों का उपयोग करना आसान समझते हैं।" - जैसा कि मैं देख रहा हूं कि गुणों को उजागर करने का एकमात्र कारण यही है। लेकिन क्या मैं सही हूं?
Tsabo

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

57

हां, यदि आप कर रहे हैं और सेटिंग कर रहे हैं, तो एक संपत्ति का उपयोग करें।

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

बीच में एक ग्रे क्षेत्र है जहां लाइन थोड़ी धुंधली हो सकती है। कोई कठिन और तेज नियम नहीं है और विभिन्न लोग कभी-कभी असहमत होंगे कि क्या कुछ संपत्ति या एक विधि होनी चाहिए। महत्वपूर्ण बात यह है कि आप इसे कैसे करते हैं (या आपकी टीम इसे कैसे करती है) के अनुरूप (अपेक्षाकृत) होना चाहिए ।

वे काफी हद तक विनिमेय हैं लेकिन उपयोगकर्ता के लिए एक संपत्ति संकेत है कि कार्यान्वयन अपेक्षाकृत "सरल" है। ओह और वाक्यविन्यास थोड़ा क्लीनर है।

सामान्यतया, मेरा दर्शन यह है कि यदि आप एक विधि नाम लिखना शुरू करते हैं जो प्राप्त या सेट के साथ शुरू होता है और शून्य या एक पैरामीटर (क्रमशः) लेता है तो यह एक संपत्ति के लिए एक प्रमुख उम्मीदवार है।


1
नीचे मतदान किया। यह सही नहीं है। एक गेट्टर या सेटर की जटिलता को गेट्टर / सेटर कोड के भीतर समझाया जाता है। यह कितना जटिल है, यह बिल्कुल भी प्रासंगिक नहीं है, न ही अगर यह "कई डेटा सदस्यों को प्रभावित करता है" तो यह सच है कि गैर-मानक या कई मापदंडों के लिए एक विधि की आवश्यकता होगी, लेकिन अन्यथा यह उत्तर सटीक नहीं है।
हल 50000

पहला वाक्य सभी को समझाता है। वाहवाही।
SWIIWII

13

गुण किसी ऑब्जेक्ट से डेटा को इंजेक्ट या पुनर्प्राप्त करने का एक तरीका है। वे एक वर्ग के भीतर चर या डेटा पर एक अमूर्त बनाते हैं। वे जावा में गेटर्स और सेटर्स के अनुरूप हैं।

विधियाँ किसी ऑपरेशन को अंजाम देती हैं।

सामान्य तौर पर मैं संपत्तियों को एकल वर्ग के डेटा, या बिक्री पर एक वर्ग, जैसे छोटे गणनाओं को उजागर करने के लिए उपयोग करता हूं। जो एक शॉपिंग कार्ट में वस्तुओं की संख्या और उनकी लागत से लिया गया है।

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

आपके कोड उदाहरण में मैं इसे एक संपत्ति में लपेटूंगा अगर मुझे इसे कक्षा से बाहर एक्सेस करने की आवश्यकता है:

public Label Title 
{
   get{ return titleLabel;}
   set{ titleLabel = value;}
}

पाठ सेट करना:

Title.Text = "Properties vs Methods";

यदि मैं केवल लेबल की पाठ संपत्ति सेट कर रहा था तो यह है कि मैं यह कैसे करूंगा:

public string Title 
{
   get{ return titleLabel.Text;}
   set{ titleLabel.Text = value;}
}

पाठ सेट करना:

Title = "Properties vs Methods";

12

यदि आप अपनी वस्तु की वास्तविक संपत्ति सेट कर रहे हैं तो आप एक संपत्ति का उपयोग करते हैं।

यदि आप एक कार्य / कार्यक्षमता का प्रदर्शन कर रहे हैं तो आप एक विधि का उपयोग करते हैं।

आपके उदाहरण में, यह एक निश्चित संपत्ति है।

हालांकि, आपकी कार्यक्षमता AppendToLabel के लिए थी तो आप एक विधि का उपयोग करेंगे।


11

MSDN के माध्यम से खोज करने पर, मुझे गुण बनाम विधियों पर एक संदर्भ मिला, जो विधियों को बनाने के लिए कुछ महान दिशानिर्देश प्रदान करता है:

  • ऑपरेशन एक रूपांतरण है, जैसे कि Object.ToString
  • ऑपरेशन काफी महंगा है कि आप उपयोगकर्ता से संवाद करना चाहते हैं कि उन्हें परिणाम का कैशिंग करने पर विचार करना चाहिए।
  • गेट एक्सेसर का उपयोग करके एक संपत्ति मूल्य प्राप्त करना एक नमूदार साइड इफेक्ट होगा।
  • उत्तराधिकार में दो बार सदस्य को बुलाने से अलग परिणाम मिलते हैं।
  • निष्पादन का क्रम महत्वपूर्ण है। ध्यान दें कि एक प्रकार के गुण किसी भी क्रम में सेट और पुनर्प्राप्त करने में सक्षम होना चाहिए।
  • सदस्य स्थिर है, लेकिन एक मूल्य देता है जिसे बदला जा सकता है।
  • सदस्य एक सरणी देता है। गुण जो सरणियाँ लौटाते हैं, वे बहुत भ्रामक हो सकते हैं। आमतौर पर आंतरिक सरणी की एक प्रति वापस करना आवश्यक होता है ताकि उपयोगकर्ता आंतरिक स्थिति को बदल न सके। यह, इस तथ्य के साथ युग्मित है कि एक उपयोगकर्ता आसानी से मान सकता है कि यह एक अनुक्रमित संपत्ति है, अक्षम कोड की ओर जाता है।

मैं मानता हूं कि यह जहां भी लागू होता है, समझ में आता है। लेकिन क्या मैं सही हूं, कि WPF में XAML बाइंडिंग के माध्यम से संपत्तियों का उपयोग करने से सेटर में उचित कार्रवाई करने के अलावा कोई विकल्प नहीं है? (विशेष रूप से कॉम्बो बॉक्स, लिस्टबॉक्स, आदि के लिए एक नया सिलेक्टेमेम पर)
निकोलस

9

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

कार्रवाई के उद्देश्य के बारे में सोचें। क्या आप वास्तव में, "एक आवश्यक या विशिष्ट विशेषता" को बदल या पुनः प्राप्त कर रहे हैं? अपने उदाहरण में, आप एक टेक्स्टबॉक्स की संपत्ति सेट करने के लिए एक फ़ंक्शन का उपयोग कर रहे हैं। यह मूर्खतापूर्ण लगता है, ऐसा नहीं है?

गुण वास्तव में कार्य हैं। वे सभी कोXXX () और सेटएक्सएक्सएक्सएक्स () प्राप्त करने के लिए संकलित करते हैं। यह उन्हें सिंटैक्टिक चीनी में छिपाता है, लेकिन यह चीनी है जो प्रक्रिया को एक अर्थपूर्ण अर्थ प्रदान करता है।

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

इस बीच, एक विधि एक कार्रवाई है। GetColor एक संपत्ति होनी चाहिए। GetFile () एक फ़ंक्शन होना चाहिए। अंगूठे का एक और नियम है, यदि यह वस्तु की स्थिति को नहीं बदलता है, तो यह एक कार्य होना चाहिए। उदाहरण के लिए, CalculatePiToNthDigit (n) एक फ़ंक्शन होना चाहिए, क्योंकि यह वास्तव में उस Math ऑब्जेक्ट की स्थिति को नहीं बदल रहा है जिससे वह जुड़ी हुई है।

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


9

सांकेतिक रूप से गुण आपकी वस्तुओं के गुण हैं। विधियाँ आपकी वस्तु का व्यवहार हैं।

लेबल एक विशेषता है और यह एक संपत्ति बनाने के लिए अधिक समझ में आता है।

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के संदर्भ में आपको स्पष्ट समझ होनी चाहिए कि व्यवहार का हिस्सा क्या है और केवल एक विशेषता क्या है।

कार {रंग, मॉडल, ब्रांड}

एक कार में रंग, मॉडल और ब्रांड विशेषताएँ होती हैं इसलिए इसका कोई मतलब नहीं है कि सेटकोलर या सेटमॉडल क्योंकि सहानुभूतिपूर्वक हम कार को अपना रंग सेट करने के लिए नहीं कहते हैं।

इसलिए यदि आप संपत्ति / विधि के मामले को वास्तविक जीवन वस्तु पर ले जाते हैं या इसे सहानुभूति के दृष्टिकोण से देखते हैं, तो आपका भ्रम वास्तव में दूर हो जाएगा।


4

प्रॉपर्टीज के लिए बड़ा प्लस यह है कि डिबगिंग के दौरान विजुअल स्टूडियो में संपत्ति का मूल्य देखा जा सकता है।


3

मैं 1 पैरामीटर के साथ ऐड / सेट विधियों के लिए गुणों का उपयोग करना पसंद करता हूं । यदि पैरामीटर अधिक हैं, तो विधियों का उपयोग करें।


3

गुणों को केवल सरल सेट होना चाहिए और एक लाइनर प्राप्त करना चाहिए। कुछ भी अधिक और इसे वास्तव में एक विधि में स्थानांतरित किया जाना चाहिए। कॉम्प्लेक्स कोड हमेशा विधियों में होना चाहिए।


3

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


3

डिजाइन के एक गुण के रूप में गुण डेटा या वर्ग वस्तु के गुणों का प्रतिनिधित्व करते हैं, जबकि विधियां वर्ग वस्तु के कार्य या व्यवहार हैं।

.Net में, दुनिया में गुणों का उपयोग करने के अन्य निहितार्थ हैं:

  • गुणों का उपयोग डेटाबाइंडिंग में किया जाता है, जबकि get_ / set_ विधियाँ नहीं हैं।
  • एक्सएमएल क्रमांकन उपयोगकर्ता गुणों को प्राकृतिककरण के प्राकृतिक तंत्र के रूप में प्रस्तुत करता है।
  • गुण द्वारा पहुँचा रहे हैं PropertyGrid नियंत्रण और प्रशिक्षु ICustomTypeDescriptor , जो प्रभावी रूप से इस्तेमाल किया जा सकता है, तो आप एक कस्टम पुस्तकालय लिख रहे हैं।
  • गुण द्वारा नियंत्रित कर रहे गुण , एक यह बुद्धिमानी से इस्तेमाल पहलू उन्मुखी सॉफ्टवेयर डिजाइन करने के लिए कर सकते हैं।

गुणों के उपयोग के बारे में गलत धारणाएं (IMHO):

  • छोटी गणना को उजागर करने के लिए उपयोग किया जाता है: ControlDesigner.SelectionRules की 72 लाइनों में ब्लॉक रन मिलते हैं !!
  • आंतरिक डेटा संरचनाओं को उजागर करने के लिए उपयोग किया जाता है: भले ही कोई संपत्ति आंतरिक डेटा सदस्य के लिए मैप नहीं करती है, कोई भी इसे संपत्ति के रूप में उपयोग कर सकता है, अगर यह आपके वर्ग की विशेषता है। कुलपति, भले ही इसके वर्ग गुणों की एक विशेषता उचित नहीं है, डेटा सदस्यों की तरह सरणी वापस करने के लिए (इसके बजाय तरीकों का उपयोग सदस्यों की गहरी प्रति लौटाने के लिए किया जाता है।)

यहाँ उदाहरण में इसे और अधिक व्यावसायिक अर्थ के साथ लिखा जा सकता है:

public String Title
{
    set { Label.Text = text; }
}

2

गुण वास्तव में अच्छे हैं क्योंकि वे दृश्य स्टूडियो के दृश्य डिजाइनर में सुलभ हैं, बशर्ते उनके पास पहुंच हो।

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

कुछ और तरीके पसंदीदा तरीका है।

यह केवल शब्दार्थ के बारे में नहीं है। विजुअल स्टूडियो विजुअल डिज़ाइनर में विचित्रता होने के कारण गुणों का अनुचित उपयोग करना।

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


1

यहाँ बिल वैगनर के गुणों बनाम विधियों का उपयोग करने के लिए दिशानिर्देशों का एक अच्छा सेट है

  • किसी संपत्ति का उपयोग तब करें जब ये सभी सत्य हों: गेटर्स सरल होना चाहिए और इस प्रकार अपवादों को फेंकने की संभावना नहीं है। ध्यान दें कि इसका मतलब है कोई नेटवर्क (या डेटाबेस) एक्सेस नहीं है। या तो विफल हो सकता है, और इसलिए एक अपवाद फेंक देंगे।
  • उनमें एक-दूसरे पर निर्भरता नहीं होनी चाहिए। ध्यान दें कि इसमें एक संपत्ति सेट करना और दूसरे को प्रभावित करना शामिल होगा। (उदाहरण के लिए, FirstName प्रॉपर्टी सेट करने से रीड-ओनली FullName प्रॉपर्टी प्रभावित होती है, जिसने प्रथम नाम + अंतिम नाम प्रॉपर्टीज़ को इस तरह की निर्भरता से जोड़ा है)
  • उन्हें किसी भी क्रम में व्यवस्थित किया जाना चाहिए
  • गेट्टर के पास एक नमूदार साइड इफेक्ट नहीं है। ध्यान दें कि यह दिशानिर्देश किसी संपत्ति में आलसी मूल्यांकन के कुछ रूपों को नहीं रोकता है।
  • विधि हमेशा तुरंत वापस आनी चाहिए। (ध्यान दें कि यह एक संपत्ति को रोकता है जो डेटाबेस एक्सेस कॉल, वेब सेवा कॉल, या अन्य समान ऑपरेशन करता है)।
  • एक विधि का उपयोग करें यदि सदस्य एक सरणी देता है।
  • गेट्टर (बार-बार कोड के बिना) के लिए बार-बार कॉल करने पर समान मान वापस करना चाहिए।
  • बार-बार सेटर को (एक ही मूल्य के साथ) एक कॉल से कोई अंतर नहीं होना चाहिए।

  • आंतरिक डेटा संरचनाओं के संदर्भ में रिटर्न को नहीं लौटना चाहिए (आइटम 23 देखें)। एक विधि एक गहरी प्रतिलिपि लौटा सकती है, और इस मुद्दे से बच सकती है।

* मेरे उत्तर से एक नकली प्रश्न पर ले जाया गया।


शीर्ष रेटेड और स्वीकृत उत्तर यहां दिए गए हैं stackoverflow.com/a/1294189/1551 नीचे क्यों?
क्रिस बैलेंस

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

0

यह सरल है।

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

2: जब आप कुछ कार्रवाई करना चाहते हैं तो पैरामीटर का उपयोग करके डेटा को पैरामीटर के रूप में आपूर्ति कर रहे हैं और आपकी विधि आपूर्ति के मूल्यों के आधार पर कुछ प्रसंस्करण कर रही है और संसाधित मूल्य को आउटपुट के रूप में वापस कर रही है। या आप इस गणना द्वारा किसी क्षेत्र का मान बदलना चाहते हैं। "इस तरह विधि क्रिया का प्रतिनिधित्व करती है"।


-1

मैं जावा से आता हूँ एक मैं मिलता है .. सेट .. थोड़ी देर के लिए विधि।

जब मैं कोड लिखता हूं, तो मैं अपने आप से नहीं पूछता: "इस डेटा तक पहुंचना सरल है या इसके लिए एक भारी प्रक्रिया की आवश्यकता है?" क्योंकि चीजें बदल सकती हैं (आज इस संपत्ति को पुनःप्राप्त करना सरल है, टोम्बो को कुछ या भारी प्रक्रिया की आवश्यकता हो सकती है)।

आज मेरे पास एक तरीका है SetAge (int age) tomonrow i में मेथड SetAge (डेट बर्थडे) भी होगा जो जन्मतिथि का उपयोग करके आयु की गणना करता है।

मुझे बहुत निराशा हुई कि कंपाइलर प्रॉपर्टी को गेट और सेट में तब्दील कर देता है लेकिन मेरे गेट ... और सेट .. के तरीकों को एक जैसा नहीं मानता।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.