2010-03-16 4 views
5

मैं जावा के लिए बहुत नया हूं, लेकिन जहां भी संभव हो, अपरिवर्तनीयता घोषित करने के लिए मैं एक आदत विकसित कर रहा हूं जो मुझे लगता है कि एक अच्छी बात है। (एफ #)जावा के लिए पर्सिस्टेंस प्रदाता जो अंतिम फ़ील्ड्स का समर्थन करता है

मैंने पढ़ा है कि जेपीए अंतिम क्षेत्रों का समर्थन नहीं करता है। हाइबरनेट, टॉपलिंक? मैं इनके बारे में निश्चित नहीं हूं लेकिन अब मैं जेपीए पसंद करता हूं।

क्या सैद्धांतिक रूप से संभव है - चलो प्रतिबिंब के माध्यम से कहें - सृजन के बाद अंतिम क्षेत्रों को संशोधित करने के लिए? मेरा अनुमान होगा ... नहीं :)

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

सुझाव?

संपादित करें: मैं अपरिवर्तनीय के लिए सटीक परिभाषा से परिचित नहीं हूं इसलिए मैंने इसे इस पोस्ट में सहजता से उपयोग किया। यहां अपरिवर्तनीयता घोषित करने का मतलब है कि एक क्षेत्र को बदला नहीं जा सकता है। गलतफहमी के लिए खेद है।

उत्तर

6

ऑब्जेक्ट अपरिवर्तनीयता (एक अपरिवर्तनीय वस्तु के बीच का अंतर नोट करें, और फ़ील्ड फाइनल घोषित करना - एक वस्तु केवल अपरिवर्तनीय है यदि सभी फ़ील्ड अंतिम हैं, तो ऑब्जेक्ट का राज्य सृजन के बाद बदल नहीं सकता है) एक बहुत ही संवेदनशील विषय है। मैं उन्हें खुद पसंद करता हूं, और हाइबरनेट उन्हें @Imutable के माध्यम से समर्थन करता है।

जेपीए 2 में इसकी स्थिति के बारे में पता नहीं है, लेकिन अंतिम फ़ील्ड के बारे में सवाल का जवाब देने के लिए: आप प्रतिबिंब का उपयोग करके अपने मूल्य बदल सकते हैं - लेकिन जावा ईई पर्यावरण में प्रतिबिंब सीमित रूप से सीमित है।

मुख्य समस्या को प्रबुद्ध करने के लिए: यदि आपके पीओजेओ अपरिवर्तनीय हैं, तो लगातार समाधान कैसे वस्तुओं को फिर से बनाएगा? मान लीजिए कि आपके पास दो अंतिम int फ़ील्ड हैं, और उन्हें प्रारंभ करने के लिए एक कन्स्ट्रक्टर है। दृढ़ता परत में उनके आदेश, या उनके नामों के बारे में कोई जानकारी नहीं हो सकती है (क्योंकि संकलन के दौरान क्षेत्र और पैरामीटर नाम मिटा दिए जाते हैं)।

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

-1

यह ईमानदारी से एक अजीब विचार है।

फ़ील्ड final बनाकर, आप संकलक को बताते हैं कि वे ऑब्जेक्ट सृजन के बाद परिवर्तन नहीं करेंगे। नतीजतन, यह एक उचित धारणा है कि उन्हें जारी न रखें, क्योंकि वे कभी नहीं बदलेंगे। खैर, यह लिखकर, मुझे लगता है कि आपके पास जावा संस्कृति है, लेकिन आप जो प्रश्न पूछते हैं वह ठीक से विपरीत बताता है।

जावा में, लगातार आज्ञाएं "हमेशा" पीओजेओ (दूसरे शब्दों में, जावा बीन्स) मानी जाती हैं। एक जावा बीन के पास एक खाली कन्स्ट्रक्टर होना चाहिए (जिसे इस तरह के रूप में माना जा सकता है) निरंतर ढांचे की अनुमति देगा और इसे अपने खाली कन्स्ट्रक्टर का उपयोग करके इसे अप्रत्यक्ष रूप से क्लास.न्यूइंस्टेंस()/के माध्यम से कॉल करके।

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

+0

केवल पढ़ने के लिए डेटाबेस के बारे में क्या? बीटीडब्ल्यू मैं बस संभावनाओं की खोज कर रहा हूँ। – naeron84

+0

अन्य उपयोग के मामले: एक तालिका के लिए एकाधिक इकाई। या कारखाने विधि के माध्यम से उन इकाइयों को बनाते हैं। – naeron84

1

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

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

0

अंतिम फ़ील्ड डिज़ाइन द्वारा सृजन के बाद संशोधित नहीं किया जा सकता है। अन्यथा करना बहुत बुरा विचार है, क्योंकि कोई मानक व्यवहार पर भरोसा कर सकता है।

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

+0

आप कुछ मान्य अंक बनाते हैं; +1। –

1

अच्छा सवाल। दरअसल, यदि वे नहीं बदलते हैं तो फ़ील्ड को अंतिम रूप में घोषित करना एक अच्छा विचार है (आप जेएमएम से प्रारंभिक गारंटी प्राप्त करते हैं)।

जेपीए युक्ति अंतिम क्षेत्रों के बारे में स्पष्ट है:

इकाई वर्ग अंतिम नहीं होना चाहिए। कोई भी विधि या इकाई वर्ग के लगातार उदाहरण चर अंतिम हो सकता है।

Hoever, नहीं सभी कार्यान्वयन इस नियम का पालन और अंतिम क्षेत्रों संभाल:

  • OpenJPA अंतिम क्षेत्रों, यानी वे क्षणिक रूप में माना जाता समर्थन नहीं करता। ऐसी इकाई के अंतिम फ़ील्ड को लोड करने पर पैरामीटर रहित कन्स्ट्रक्टर में परिभाषित के मानों के साथ प्रारंभ किया गया है।

  • हाइबरनेट कार्यान्वयन हालांकि अंतिम क्षेत्रों का समर्थन करता है। निर्माण पर अंतिम फ़ील्ड जो पैरामीटर रहित कन्स्ट्रक्टर में प्रारंभ किया गया है, को डेटाबेस में संग्रहीत मानों के साथ प्रतिस्थापित किया गया है।

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

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