गायब "ढांचा स्तर" पहुंच संशोधक

Question

यहां परिदृश्य है। सार्वजनिक रूप से लाइसेंस प्राप्त, ओपन सोर्स एपीआई के निर्माता के रूप में, मेरे समूह ने जावा-आधारित वेब यूजर इंटरफेस फ्रेमवर्क बनाया है (तो नया क्या है?)। जावा में किसी के रूप में अच्छी चीजों को व्यवस्थित और संगठित रखने के लिए, हमने नामकरण सम्मेलन org.mygroup.myframework.x के साथ संकुल का उपयोग किया है, एक्स के साथ घटक, सत्यापनकर्ता, कन्वर्टर्स, उपयोगिताओं, आदि जैसे चीजें हैं (फिर से, और क्या नया है?)।

अब, कक्षा org.mygroup.myframework.foo.Bar में कहीं भी एक विधि void doStuff() है कि मुझे अपने ढांचे के लिए विशिष्ट तर्क करने की आवश्यकता है, और मुझे इसे अपने ढांचे में कुछ अन्य स्थानों से कॉल करने में सक्षम होना चाहिए , उदाहरण के लिए org.mygroup.myframework.far.Boo। यह देखते हुए कि बू न तो बार का उप-वर्ग है और न ही उसी पैकेज में, विधि doStuff() को बू द्वारा कॉल करने योग्य घोषित किया जाना चाहिए।

हालांकि, मेरा ढांचा अन्य डेवलपर्स को अपने ग्राहकों के लिए सरल और अधिक सुरुचिपूर्ण R.I.A.s बनाने की अनुमति देने के लिए एक उपकरण के रूप में मौजूद है। लेकिन अगर com.yourcompany.yourapplication.YourComponent कॉल करता है DoStuff(), यह अप्रत्याशित और अवांछित परिणाम हो सकता है। मैं पसंद करूंगा कि इसे कभी होने की अनुमति नहीं दी जाएगी। ध्यान दें कि बार में अन्य विधियां हैं जो वास्तव में सार्वजनिक हैं।

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

[org.mygroup.myframework.*] void doStuff() { .... } 

जहां वाइल्डकार्ड किसी भी वर्ग जिसका पैकेज org.mygroup.myframework साथ शुरू होता है कॉल कर सकते हैं मतलब होगा, लेकिन और कोई नहीं।

यह देखते हुए कि यह दुनिया मौजूद नहीं है, हमारे पास अन्य अच्छे विकल्प क्या हैं?

---

ध्यान दें कि यह वास्तविक जीवन परिदृश्य से प्रेरित है; दोषी की रक्षा के लिए नाम बदल दिए गए हैं। एक वास्तविक ढांचा मौजूद है जहां अपने जावाडोक में पेपर किया गया है, सार्वजनिक तरीकों से यह टिप्पणी की जाएगी कि "यह तरीका MYFRAMEWORK के लिए आंतरिक है और अपने सार्वजनिक एपीआई का हिस्सा नहीं है। कॉल न करें !!!!!!" एक छोटे से शोध से पता चलता है कि इन तरीकों को ढांचे के भीतर कहीं और कहा जाता है।

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

---

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

package org.mygroup.myframework.foo; 
public class Bar { 
    /** Adds a Bar component to application UI */ 
    public boolean addComponentHTML() { 
     // Code that adds the HTML for a Bar component to a UI screen 
     // returns true if successful 
     // I need users of my framework to be able to call this method, so 
     // they can actually add a Bar component to their application's UI 
    } 

    /** Not really public, do not call */ 
    public void doStuff() { 
     // Code that performs internal logic to my framework 
     // If other users call it, Really Bad Things could happen! 
     // But I need it to be public so org.mygroup.myframework.far.Boo can call 
    } 
} 

---

कोई अन्य अपडेट: तो मैं अभी सीखा सी # "आंतरिक" पहुँच संशोधक है। तो शायद इस सवाल का phrased करने का एक बेहतर तरीका हो सकता है, "जावा में आंतरिक पहुंच अनुकरण/अनुकरण कैसे करें?" फिर भी, मैं नए उत्तरों की तलाश में नहीं हूं।हमारे मालिक अंततः चिंताओं

Answer 1

जब आप दस्तावेज़ समस्या का उल्लेख करते हैं तो आप जवाब के सबसे नज़दीकी होते हैं। वास्तविक मुद्दा यह नहीं है कि आप अपनी आंतरिक विधियों को "सुरक्षित" नहीं कर सकते; बल्कि, यह है कि आंतरिक तरीके आपके दस्तावेज़ को प्रदूषित करते हैं और जोखिम को पेश करते हैं जो क्लाइंट मॉड्यूल गलती से आंतरिक विधि को कॉल कर सकता है।

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

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

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

Answer 2

केवल विचार मैं इस लापता "फ्रेमवर्क स्तर तक पहुँच संशोधक" की आपूर्ति करने में सोच सकते हैं कि CDI है कि ऊपर उल्लेख किया और एक बेहतर डिजाइन के साथ सहमति व्यक्त की। यदि आपको विभिन्न (लेकिन कुछ) परिस्थितियों में बहुत अलग वर्गों और पैकेजों से एक विधि का उपयोग करना है, तो उन तरीकों को "निजी" और अपरिवर्तनीय बनाने के लिए निश्चित रूप से उन वर्गों को फिर से डिजाइन करने का एक तरीका होगा।

Answer 3

पहुंच का स्तर इस तरह के लिए जावा भाषा में कोई समर्थन नहीं है (यदि आप नाम स्थान के साथ "आंतरिक" की तरह कुछ करना चाहते हैं)। आप केवल पैकेज स्तर तक पहुंच प्रतिबंधित कर सकते हैं (या ज्ञात विरासत सार्वजनिक-संरक्षित-निजी मॉडल)।

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

वैसे, एक्लिप्स प्लेटफ़ॉर्म स्रोत कोड में, एक जटिल प्लगइन मॉडल है जो आपको प्रत्येक प्लगइन के लिए कस्टम क्लास लोडर को लागू करके अन्य प्लगइन के आंतरिक कोड का उपयोग न करने के लिए मजबूर करता है जो कक्षाओं को लोड करने से रोकता है जो "आंतरिक" होना चाहिए ये प्लगइन्स

Answer 4

इंटरफेस और गतिशील प्रॉक्सी कभी कभी यकीन है कि आप केवल तरीकों कि आप को बेनकाब करना चाहते हैं का पर्दाफाश करने के लिए उपयोग किया जाता है।

हालांकि, यदि आपकी विधियों को अक्सर बुलाया जाता है तो यह काफी भारी प्रदर्शन लागत पर आता है।

@Deprecated एनोटेशन का उपयोग करना एक विकल्प भी हो सकता है, हालांकि यह बाहरी उपयोगकर्ताओं को आपके "ढांचे के निजी" तरीकों का आह्वान नहीं करेगा, वे यह नहीं कह सकते कि उन्हें चेतावनी नहीं दी गई थी।

सामान्य तौर पर मुझे नहीं लगता कि आप अपनी उपयोगकर्ता जानबूझ कर बहुत ज्यादा पैर में खुद को शूटिंग के बारे में चिंता करनी चाहिए जब तक कि आप यह उनके लिए स्पष्ट कर दिया कि वे कुछ उपयोग नहीं करना चाहिए है।