क्या जावा के सार्वजनिक क्षेत्र इस बिंदु पर एक दुखद ऐतिहासिक डिजाइन दोष हैं? [बन्द है]


17

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

धन्यवाद!

अपडेट: मैं अधिक सुरुचिपूर्ण दृष्टिकोणों के बारे में जानता हूं, जैसे कि सी #, पायथन, ग्रूवी, आदि। मैं सीधे उन उदाहरणों की तलाश में नहीं हूं। मैं वास्तव में सोच रहा था कि अगर वहाँ अभी भी एक बंकर में कोई गहरा है, तो वास्तव में कैसे अद्भुत सार्वजनिक क्षेत्र हैं, और कैसे जनता सभी भेड़, आदि हैं।

अद्यतन 2: स्पष्ट रूप से स्थिर अंतिम सार्वजनिक क्षेत्र सार्वजनिक स्थिरांक बनाने का मानक तरीका है। मैं वस्तु क्षेत्र (यहां तक ​​कि अपरिवर्तनीय राज्य) के लिए सार्वजनिक क्षेत्रों का उपयोग करने के लिए अधिक उल्लेख कर रहा था। मैं सोच रहा हूं कि यह एक डिजाइन दोष की तरह प्रतीत होता है कि किसी व्यक्ति को स्थिरांक के लिए सार्वजनिक क्षेत्रों का उपयोग करना चाहिए, लेकिन राज्य के लिए नहीं ... एक भाषा के नियमों को स्वाभाविक रूप से, सिंटैक्स द्वारा लागू किया जाना चाहिए, दिशानिर्देशों द्वारा नहीं।


2
आपका आधार क्या है कि वे वास्तव में एक दोष हैं?
एरोन मैकिवर

1
क्या जावा में अब प्रतीकात्मक स्थिर अभिव्यक्ति बनाने का एक अलग तरीका है?
एडवर्ड स्ट्रेंज

@ ऐरन मैं यह नहीं कह रहा था कि वे एक दोष हैं, मैं यह कह रहा था कि मैंने इसे इस बिंदु पर रूढ़िवादी माना है कि कभी भी सार्वजनिक क्षेत्रों का उपयोग नहीं करना चाहिए। यह धारणा गलत हो सकती है, लेकिन यह वास्तव में वही है जो मैंने माना है।
एवी फ्लैक्स

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

जवाबों:


14

मैं उन्हें पसंद करता हूं, जब तक कि क्षेत्र अंतिम है और केवल एप्लिकेशन में आंतरिक रूप से उपयोग किया जाता है, अन्य एप्लिकेशन के लिए एपीआई में उजागर नहीं किया जाता है। यह आपके कोड को छोटा और अधिक पठनीय रखता है।

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

यह अपरिवर्तनीय वर्गों public finalमें खेतों के लिए एक व्यवहार्य डिजाइन है ।

से प्रभावी जावा :

आइटम 14: सार्वजनिक कक्षाओं में, सार्वजनिक क्षेत्रों में नहीं, एक्सेसर विधियों का उपयोग करें

... यदि एक वर्ग पैकेज-निजी है या एक निजी नेस्टेड वर्ग है, तो इसके डेटा फ़ील्ड को उजागर करने में स्वाभाविक रूप से कुछ भी गलत नहीं है। यह दृष्टिकोण एक्सेसर-विधि दृष्टिकोण की तुलना में कम अव्यवस्था उत्पन्न करता है।

जबकि सार्वजनिक क्षेत्र के लिए सीधे खेतों को उजागर करना एक अच्छा विचार नहीं है, अगर यह खेतों में अपरिवर्तनीय है तो यह कम हानिकारक है।

यह भी देखें कि मुझे JavaBeans के बजाय अपरिवर्तनीय POJOs का उपयोग क्यों नहीं करना चाहिए?


बस सोच रहा था, एपीआई में इसे उजागर न करने के आपके क्या कारण हैं?
स्टीवन ज्यूरिस

2
@ उत्तर: क्योंकि सार्वजनिक क्षेत्रों को उजागर करने से, आप कार्यान्वयन को भी उजागर करते हैं। यदि आप getXXX()इसके बजाय इसे एक विधि के रूप में उजागर करते हैं , तो आप एपीआई इंटरफ़ेस को बदले बिना कार्यान्वयन को बदल सकते हैं। उदाहरण के लिए, आप रिमोट सेवा से मूल्य बदल सकते हैं और प्राप्त कर सकते हैं, लेकिन एपीआई का उपयोग करने वाले अनुप्रयोगों को यह जानने की आवश्यकता नहीं है।
जोनास

@ जोनास: वे आम तौर पर पहली बार स्थिरांक के उम्मीदवार नहीं हैं।
स्टीवन ज्यूरिस

@Steven: मैं पहली जगह में स्थिरांक लेकिन के बारे में बात नहीं कर रहा हूँ सार्वजनिक अंतिम में खेतों अपरिवर्तनीय कक्षाएं। उदाहरण के लिए, मुझे JavaBeans के बजाय अपरिवर्तनीय POJOs का उपयोग क्यों नहीं करना चाहिए?
जोनास

@ जोनास: यह एक अच्छा उपयोग मामला भी है! शायद यह स्पष्ट करने के लिए अपने उत्तर को थोड़ा अपडेट करने में मददगार है।
स्टीवन ज्यूरिस

9

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


1
जबकि सच है, यह सवाल के बिंदु के लिए कुछ हद तक स्पर्शनीय है, जो (अनिवार्य रूप से) है कि सेट / पाने के तरीकों और सार्वजनिक क्षेत्रों के बीच विकल्प दिया गया है, क्या किसी भी स्थिति में खेतों को पसंद करने के लिए कोई अच्छा कारण हैं? इस समस्या के बेहतर समाधान के लिए अन्य भाषाएं मुझे अप्रासंगिक लगती हैं।
जूल्स १

5

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


2
java.awt.Pointऔर दोस्तों एक बुरा सपना है।
टॉम हॉल्टिन -

@ टॉमहॉटिन-टैक्लाइन: इसके साथ समस्या Pointयह है कि यह अस्पष्ट है कि क्या किसी प्रकार का वैरिएबलPoint किसी स्थान को एनकैप्स्युलेट करने वाला है, या किसी ऐसी इकाई की पहचान को अतिक्रमण करने वाला माना जाता है जो बदल सकती है। वैचारिक रूप से, मैं कोड के बारे में सोचता हूं जो Pointकोड के समान होता है जो कि सरणियों के आसपास से गुजरता है।
सुपरकैट

इसलिए अगर मुझे एक मिलता है Pointऔर इसे संशोधित करता है, तो मुझे स्क्रीन पर सफाई से अद्यतन करने के लिए संदर्भित वस्तु की अपेक्षा करनी चाहिए? नहीं, इसके साथ समस्या Pointयह है कि यह परिवर्तनशील है। हम था String/ StringBufferलेकिन विचार के माध्यम से प्राप्त करने के लिए नहीं मालूम था। / आसपास सरणियों में समान समस्याएं हैं।
टॉम हॉल्टिन -

5

सार्वजनिक स्थिरांक को परिभाषित करने के लिए यह अभी भी उपयोगी है। उदाहरण के लिए

सार्वजनिक स्थिर अंतिम int DAYS_IN_WEEK = 7;

हालाँकि, अभी भी enum पसंद करते हैं जहाँ संभव है। उदाहरण के लिए

public enum Day {
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY, 
    THURSDAY, FRIDAY, SATURDAY 
}

सरल संरचना वर्गों का अनुकरण करने के लिए यह उपयोगी है। हर क्षेत्र के लिए एक गेटटर और सेटर बनाने का कोई कारण नहीं है, जब वे किसी भी तरह से सार्वजनिक होते हैं।

class Point
{
    public int x, y;
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

लेकिन तब फिर से, कई लोगों का तर्क होगा कि जावा जैसी भाषा में कोई स्थान नहीं है ...

1
@delnan: वे लगभग JavaBeans के समान हैं, लेकिन JavaBeans बहुत अधिक क्रियात्मक है और न कि थ्रेडसेफ़। देखें कि मुझे JavaBeans के बजाय अपरिवर्तनीय POJOs का उपयोग क्यों नहीं करना चाहिए?
जोनास

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

2

इससे पहले कि आईडीई व्यापक हो जाता, आपके सभी क्षेत्रों को सार्वजनिक करना एक शक्तिशाली उपकरण था, जो अवधारणाओं के प्रोटोटाइप / प्रमाण बनाने के लिए एक शक्तिशाली उपकरण था।

आजकल उनका उपयोग करने के लिए बहुत कम बहाना है, जब आप माउस के एक क्लिक के साथ एक गेट्टर / सेटर जोड़ी उत्पन्न कर सकते हैं।


4
लेकिन 10 public finalक्षेत्र 10 getXXX()विधियों से अधिक पठनीय हैं ।
जोनास

1
@ जोनास हाँ, लेकिन हम यहाँ अंतिम फ़ील्ड के बारे में बात नहीं कर रहे हैं। यदि आपके सार्वजनिक अंतिम फ़ील्ड भी स्थिर हैं, तो वे स्थिरांक हैं, और एक constकीवर्ड पर्याप्त होगा, यदि वे स्थिर नहीं हैं, तो वे इनकैप्सुलेशन का गंभीर उल्लंघन हैं।
biziclop

3
विकिपीडिया के अनुसार @biziclop : "हालांकि जावा में एक खोजशब्द के रूप में आरक्षित है, कांस्ट का उपयोग नहीं किया गया है और इसका कोई कार्य नहीं है"
एवी फ्लैक्स

@ एवी फ्लैक्स हाँ, लेकिन इसका उपयोग स्थिरांक को चिह्नित करने के लिए किया जा सकता था, इस प्रकार स्थिरांक को सार्वजनिक क्षेत्र घोषित करने की आवश्यकता समाप्त हो गई।
biziclop

2
एक गेटर / सेटर जोड़ी को उचित मान लेना, वह है। यह अक्सर नहीं है।
डेविड थॉर्नले

2

यह व्यक्तिपरक है, लेकिन मेरी राय है कि पूरी सार्वजनिक / निजी धारणा पुरानी और पीछे की ओर है।

अजगर में कोई सार्वजनिक / निजी नहीं है; सब कुछ मूल रूप से सार्वजनिक है। कई समस्याओं का कारण नहीं है।

जावा में आप "सार्वजनिक" अंकन के पाप से बचने के लिए प्रत्येक क्षेत्र के लिए निरर्थक गेटर्स / सेटर बनाते हैं। (IMHO यदि आप खुद को ऐसा करते हुए पाते हैं कि आपको उन्हें सार्वजनिक रूप से चिह्नित करना चाहिए)।


पायथन आपको __ के साथ नामों को उपसर्ग करके चीजों को निजी के रूप में चिह्नित करने की अनुमति देता है। यह 100% निजी नहीं है, क्योंकि अभी भी उन चर और तरीकों तक पहुंचने के तरीके हैं, लेकिन फिर सी # में आप इसी तरह की चीजों को प्रतिबिंब के साथ कर सकते हैं।
एडम लेअर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.