जावा में स्वचालित गुण क्यों नहीं हैं जैसे सी #?

Question

C# में स्वचालित गुण हैं जो आपके कोड को बहुत सरल बनाते हैं:

public string Name { get; set; } 
public string MiddleName { get; set; } 
public string LastName { get; set; } 

जबकि जावा ने आपको यह कोड लिखा है:

private String name; 
private String middleName; 
private String LastName; 

public String Name(){ 
    return this.name; 
} 

etc.. 

क्या कोई विशेष कारण जावा ने ऐसा कुछ लागू नहीं किया है?

Answer 1

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

तो, यह भाषा में जोड़ने का सिर्फ एक प्रश्न नहीं है; आपको बहुत सावधानी से सोचना होगा, और यह पता लगाने के लिए कि क्या कोई भी नई सुविधा जो आप जोड़ना चाहते हैं, वहां कोई सूक्ष्म पिछड़ा संगतता समस्या नहीं है।

जावा में एक रूप में या किसी अन्य रूप में गुणों के लिए समर्थन जोड़ने के प्रस्ताव दिए गए हैं, लेकिन ऐसा लगता है कि जावा 7 (अगला संस्करण आ रहा है) यह एक ऐसी विशेषता नहीं है जिसे माना जा रहा है।

आप Project Lombok पर एक नज़र डालना चाहते हैं, जो एनोटेशन का उपयोग करके जावा के लिए एक प्रकार का विस्तार है, ताकि अधिक संक्षिप्त कोड लिखना संभव हो सके (उदाहरण के लिए, फ़ील्ड के लिए स्वचालित रूप से गेटर्स और सेटर्स उत्पन्न कर सकते हैं) ।

Answer 2

हाँ, क्योंकि इसमें यह नहीं है। जैसा कह रहा है, सभी सुविधाएं अनुपूरक शुरू होती हैं।

Answer 3

.net जावा के साथ आया था, और इसके लक्ष्यों में से एक COM के साथ अंतःक्रिया करना था। COM में संपत्तियां थीं, संभवतः एक ला वीबी, इसलिए .net सभी को भाषाओं को अंतःक्रियाशील बनाने के लिए उन्हें जोड़ना पड़ा। (वह, और वे एक सुंदर स्पिफी विचार थे।)

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

Answer 4

इसी कारण से सी # 2.0 या उससे कम के पास यह नहीं है। यह अधिक या वाक्य रचनात्मक चीनी बल्कि एक भाषा सुविधा है। इस तरह की कई विशेषताएं हैं जिन्हें किसी भी भाषा में जोड़ा जा सकता है, लेकिन कोई नहीं जानता कि वे भाषा क्यों नहीं हैं।

Answer 5

स्वचालित गुण गुणों पर बनाए जाते हैं। सी # में

गुण जावा में वे एक सम्मेलन कर रहे हैं एक भाषा विशेषता है, (प्राप्त या सेट के साथ शुरू तरीके अक्सर कोड के बारे में बात लोगों द्वारा गुण माना जाता है, लेकिन संकलक करने के लिए इसे foo या बार से अलग नहीं है)।

नेट और इससे संबंधित भाषाओं जहां कई मायनों (कभी कभी सूट निम्नलिखित में, कभी-कभी जानबूझकर नहीं कॉम में कुछ ऐसा है जो किसी न किसी कारण अलोकप्रिय के लिए था कर में) कॉम पर आधारित है।

COM में गुणों की एक अवधारणा है जो वीबी में भाषा सुविधाओं द्वारा समर्थित थी (सी ++ में इसे सम्मेलनों द्वारा समर्थित किया गया था)।

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

तो सभी में, जबकि सी # जावा के साथ सी/सी ++ विरासत साझा करता है, लेकिन इसमें एक विरासत भी होती है जो जावा साझा नहीं करता है, जो गुणों को सी # के रचनाकारों के लिए एक अच्छा विचार प्रतीत होता है, लेकिन जावा के लिए नहीं।

संपादित करें: सबसे पहले मैं ने कहा:

---

व्यक्तिगत रूप से, मुझे लगता है कि स्वत: गुण वास्तव में अपने कोड को आसान बनाने के लिए एक रास्ता गुण में एक दोष के लिए एक समाधान के बजाय कर रहे हैं। गुण सार्वजनिक रूप से सार्वजनिक क्षेत्रों की तरह "देखो", लेकिन पूरी तरह से नहीं हैं (फ़ील्ड पुनर्प्राप्त करने के लिए DataBinder.Eval का उपयोग करने का प्रयास करें)। अगर कोई संपत्ति पूरी तरह से सार्वजनिक थी, और गेटटर या सेटर (जो स्वचालित गुणों के साथ मामला है) में कोई अतिरिक्त कार्यक्षमता नहीं थी, तो मेरे पास सिर्फ एक सार्वजनिक क्षेत्र होगा (encapsulation यहां कोई तर्क नहीं है, क्योंकि इसे सार्वजनिक रूप से पूरी तरह से उजागर करना है- वैसे भी गुजरता है), लेकिन इसके खिलाफ खेतों और गुणों के बीच मतभेद काम करता है।

---

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