मुझे नहीं लगता कि भाषा-अज्ञेय का इस पर कोई जवाब है क्योंकि "संपत्ति" का गठन एक भाषा-विशिष्ट प्रश्न है, और "संपत्ति" की अपेक्षा करने वाला व्यक्ति एक भाषा-विशिष्ट प्रश्न भी है। मुझे लगता है कि इस बारे में सोचने का सबसे फलदायी तरीका यह है कि यह सोचने के लिए कि यह देखने वाले के दृष्टिकोण से कैसा दिखता है।
C # में, गुण विशिष्ट हैं कि वे (पारंपरिक रूप से) पूंजीकृत हैं (विधियों की तरह) लेकिन उनमें कोष्ठक (सार्वजनिक उदाहरण चर की तरह) की कमी है। यदि आप निम्नलिखित कोड, अनुपस्थित प्रलेखन देखते हैं, तो आप क्या उम्मीद करते हैं?
var reciprocalHeading = myHeading.Reciprocal;
एक रिश्तेदार सी # नौसिखिए के रूप में, लेकिन जो Microsoft की संपत्ति उपयोग दिशानिर्देशों को पढ़ता है , मैं Reciprocalअन्य चीजों के बीच की अपेक्षा करूंगा:
Headingकक्षा का तार्किक डेटा सदस्य हो- कॉल करने के लिए सस्ती हो, जैसे कि मेरे लिए मूल्य को कैश करने की कोई आवश्यकता नहीं है
- कमी देखने योग्य दुष्प्रभाव
- एक ही परिणाम का उत्पादन अगर दो बार उत्तराधिकार में कहा जाता है
- (शायद) एक
ReciprocalChangedघटना की पेशकश करते हैं
इन मान्यताओं में से, (3) और (4) शायद सही हैं (मान Headingलेना एक अपरिवर्तनीय मूल्य प्रकार है, जैसा कि इवान के उत्तर में है ), (1) बहस योग्य है, (2) अज्ञात है, लेकिन यह भी बहस योग्य है, और (5) संभावना नहीं है अर्थ समझ बनाने (हालांकि जो कुछ भी है एक शीर्षक शायद एक होना चाहिए HeadingChangedघटना)। इससे मुझे पता चलता है कि C # API में, "प्राप्त करें या पारस्परिक गणना करें" को एक संपत्ति के रूप में लागू नहीं किया जाना चाहिए , लेकिन विशेष रूप से यदि गणना सस्ती है और Headingअपरिवर्तनीय है, तो यह एक सीमावर्ती मामला है।
(ध्यान दें, हालांकि, इन चिंताओं में से कोई भी कुछ नहीं है कि संपत्ति को कॉल करने से एक नया उदाहरण बनता है , यहां तक कि (2) भी नहीं। सीएलआर में वस्तुओं का निर्माण करना, और अपने आप में बहुत सस्ता है।)
जावा में, गुण एक विधि नामकरण सम्मेलन हैं। अगर मैं देखूँ
Heading reciprocalHeading = myHeading.getReciprocal();
मेरी अपेक्षाएं ऊपर वाले (यदि कम स्पष्ट रूप से निर्धारित की गई हैं) के समान हैं: मुझे उम्मीद है कि कॉल सस्ता, सुस्पष्ट और साइड इफेक्ट्स की कमी होगी। हालाँकि, JavaBeans के बाहर "प्रॉपर्टी" की अवधारणा सभी जावा में सार्थक नहीं है, और विशेष रूप से जब बिना किसी संबंधित संपत्ति के साथ विचार किया जाता है setReciprocal(), तो यह getXXX()सम्मेलन अब कुछ हद तक पुराना है। से प्रभावी जावा , द्वितीय संस्करण (पहले से ही आठ से अधिक वर्षों के अब पुराना हो):
वे विधियाँ जो किसी गैर- booleanफ़ंक्शन या उस ऑब्जेक्ट की विशेषता को लौटाती हैं, जिस पर उनका उपयोग किया जाता है, आमतौर पर एक संज्ञा, संज्ञा वाक्यांश या क्रिया के साथ शुरू होने वाली क्रिया वाक्यांश के साथ नामित किया जाता है get। एक मुखर आकस्मिकता है जो दावा करती है कि केवल तीसरा रूप (शुरुआत get) स्वीकार्य है, लेकिन इस दावे का बहुत कम आधार है। पहले दो रूपों में आमतौर पर अधिक पठनीय कोड होता है ... (पृष्ठ 239)
समकालीन, अधिक धाराप्रवाह एपीआई में, फिर, मैं देखने की उम्मीद करूंगा
Heading reciprocalHeading = myHeading.reciprocal();
- जो फिर से सुझाव देगा कि कॉल सस्ता है, बेरोजगार है, और साइड इफेक्ट्स का अभाव है, लेकिन इस बारे में कुछ नहीं कहेंगे कि एक नई गणना की जाती है या एक नई वस्तु बनाई जाती है। यह ठीक है; एक अच्छे एपीआई में, मुझे परवाह नहीं करनी चाहिए।
रूबी में, संपत्ति जैसी कोई चीज नहीं है। "विशेषताएँ" हैं, लेकिन अगर मैं देखूं
reciprocalHeading = my_heading.reciprocal
मेरे पास यह जानने का कोई तात्कालिक तरीका नहीं है कि मैं एक इंस्टेंस वेरिएबल @reciprocalको एक्सेस कर रहा हूं attr_readerया सिंपल एक्सेसर मेथड के माध्यम से , या क्या मैं एक ऐसा तरीका कह रहा हूं जो एक महंगी गणना करता है। तथ्य यह है कि विधि का नाम एक सरल संज्ञा है, हालांकि, कहने के बजाय calcReciprocal, फिर से, सुझाव देता है कि कॉल कम से कम सस्ती है और शायद इसके दुष्प्रभाव नहीं हैं।
स्काला में, नामकरण सम्मेलन है कि साइड इफेक्ट्स वाले तरीके कोष्ठक लेते हैं और उनके बिना तरीके नहीं हैं, लेकिन
val reciprocal = heading.reciprocal
इनमें से कोई भी हो सकता है:
// immutable public value initialized at creation time
val reciprocal: Heading = …
// immutable public value initialized on first use
lazy val reciprocal: Heading = …
// public method, probably recalculating on each invocation
def reciprocal: Heading = …
// as above, with parentheses that, by convention, the caller
// should only omit if they know the method has no side effects
def reciprocal(): Heading = …
(ध्यान दें कि स्काला विभिन्न चीजों को अनुमति देता है जो शैली गाइड द्वारा हतोत्साहित किया जाता है । यह स्काला के साथ मेरे प्रमुख कष्टों में से एक है।)
कोष्ठक की कमी मुझे बताती है कि कॉल के दुष्प्रभाव नहीं हैं; नाम, फिर से, सुझाव है कि कॉल अपेक्षाकृत सस्ता होना चाहिए। इसके अलावा, मुझे परवाह नहीं है कि यह मुझे कैसे मूल्य देता है।
संक्षेप में: उस भाषा को जानें, जिसका आप उपयोग कर रहे हैं, और यह जान लें कि अन्य प्रोग्रामर आपके एपीआई पर क्या उम्मीदें लगाएंगे। बाकी सब कुछ एक कार्यान्वयन विवरण है।
Headingएक अपरिवर्तनीय प्रकार के रूप में औरreciprocalएक नया रिटर्न "सफलता का पिटाराHeading" अच्छा अभ्यास है। (दो कॉल पर कैवेट के साथreciprocal"एक ही बात" लौटना चाहिए, अर्थात उन्हें समानता परीक्षण पास करना चाहिए।)