2012-01-31 7 views
5

ठीक है, एक आसान सवाल है।संपत्ति गेटटर में मूल्यांकन करते समय या एक उदाहरण बनाते समय?

सबसे पहले, मुझे यह कहना है कि मेरी चिंता प्रदर्शन नहीं है। मुझे पूरी तरह से पता है कि जो भी प्रदर्शन एक विकल्प खर्च करता है या दूसरा हो सकता है वह संभवतः व्यर्थ है और सामान्य परिदृश्यों पर विचार करने के लायक भी नहीं है। डिजाइन मानकों और जिज्ञासा के साथ इसका अधिक संबंध है कि कैसे अधिकांश कोडर इसे करेंगे।

ठीक है, तो सवाल नहीं बल्कि सरल है:

मान लीजिए मैं एक ComplexNumberstruct जो मैं निम्नलिखित तरीके से लागू हो सकता है:

public struct Complex : IEquatable<Complex>, IFormattable 
{ 
    readonly double realPart, imaginaryPart, magnitude, argument; 
    readonly static Complex j = new Complex(0, 1); 

    public Complex(double realPart, double imaginaryPart) 
    { 
     this.realPart = realPart; 
     this.imaginaryPart = imaginaryPart; 
     this.magnitude = Math.Sqrt(Math.Pow(realPart, 2) + Math.Pow(imaginaryPart, 2)); 
     this.argument = Math.Atan2(imaginaryPart, realPart); 
    } 

    public double RealPart { get { return this.realPart; } } 
    public double ImaginaryPart { get { return this.imaginaryPart; } } 
    public double Magnitude { get { return this.magnitude; } } 
    public double Argument { get { return this.argument; } } 

    public static Complex J { get { return Complex.j; } } 
    ... 
} 

Magnitude और Argument गुण क्षेत्रों हैं कि समर्थन किया है निर्माण समय पर मूल्यांकन किया। एक अन्य विकल्प केवल गेटटर में इसी मूल्य का मूल्यांकन करना होगा।

ऐसा करने का सबसे अनुशंसित तरीका क्या है? क्या कोई कोडिंग मानक है जो मानक रखने के लिए किसी भी विकल्प की सिफारिश करता है? और यदि कोई नहीं है, तो आमतौर पर पसंदीदा विकल्प क्या होता है? या यह केवल प्रदर्शन निर्भर है जो मेरे मामले में अप्रासंगिक है?

उत्तर

1

[नीचे UPDATED:]

क्यों गेटर में मूल्यांकन करें और सेटर में नहीं? मैं मूल्य के मूल्यांकन के रूप में मूल्यांकन करूँगा। इस तरह सही मूल्य का उपयोग निजी तरीकों से किया जा सकता है।

सीटर में डिफ़ॉल्ट सेट करें, सेटटर में मूल्यांकन करें।

आप इसे हमेशा सेट करने से अधिक मूल्य पढ़ेंगे, इसलिए प्रदर्शन कारणों से आपको सेटटर में मूल्यांकन करना चाहिए - यह अक्सर कम चला जाएगा।

[अद्यतन:] यदि संपत्ति केवल पढ़ने के लिए ही है, तो उपरोक्त के समान तर्क के लिए ctor में मूल्यांकन करें (प्रदर्शन - आप केवल एक बार मूल्यांकन करेंगे)। मुझे पता है कि आप कहते हैं कि प्रदर्शन कोई मुद्दा नहीं है, लेकिन अगर बेहतर प्रदर्शन करने में ऐसा न करने का कोई कारण नहीं है तो इसे ऐसा किया जाना चाहिए।

+2

एहम, कोड में कोई सेटर्स नहीं हैं। – svick

+1

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

+0

बेशक, – hofnarwillie

0

C'tor सदस्यों को डिफ़ॉल्ट मानों के साथ प्रारंभ करना चाहिए।

निश्चित रूप से, यदि आप कोड को गेटटर पर ले जाते हैं तो प्रदर्शन समस्या हो सकती है क्योंकि आप हर बार गेटर नामक मूल्यांकन करेंगे।

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

और आपको गंदे मूल्यों के उपयोग से बचने की भी कोशिश करनी चाहिए। यदि आप गेटटर में Magnitude (कहें) सेट करते हैं लेकिन इसे कक्षा में सीधे एक्सेस करने का प्रयास करें; आप गलत मूल्य का उपयोग करने में समाप्त हो सकते हैं।

इसलिए, यदि प्रश्न सदस्य चर को निष्क्रिय करने के बारे में है, तो इसे c'tor में करें। यही कारण है कि यह भाषा डिजाइनरों द्वारा बनाया गया है।

+0

सवाल सदस्य चर प्रारंभ करने के बारे में नहीं है। जब यह * मूल्य प्रकार * की बात आती है तो यह सवाल म्यूट होता है क्योंकि ऐसा करना अनिवार्य है। सवाल यह है कि सदस्य चर के साथ शुरुआत करने के लायक है। – InBetween

+2

मैं असहमत हूं कि गेटर्स में गणना से बचा जाना चाहिए। विशेष रूप से यदि यह अपेक्षाकृत सरल कोड है। – svick

+0

@InBetween: हाँ, अगर स्मृति कोई मुद्दा नहीं है। आवश्यकता के रूप में यह अधिक स्केलेबल होगा। – Azodious

1

मैं सीधे गेटर्स में मूल्यों की गणना करने का पक्ष लेगा, क्योंकि यह अधिक पठनीय है: यदि आप जानना चाहते हैं कि Argument क्या करता है, तो बस उसका कोड देखें। यदि आपने अब क्षेत्र में मूल्य को कैश किया है, तो आपको Argument संपत्ति → argument फ़ील्ड → कन्स्ट्रक्टर जाना होगा।

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

+0

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

+0

@svick: अगर केवल यह कोड माना जाता है, तो गेटटर में कोड डालना ठीक है। लेकिन इसे सामान्य नियम के रूप में देखते हुए, मैं इसे पसंद नहीं करूंगा। – Azodious

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

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