जावाबीन और आत्मनिरीक्षण - बूलियन और अनुक्रमित गुणों पर गड़बड़?

Question

मेरा एक पूर्व सहयोगी ने जावाबीन के बारे में आधे घंटे पहले एक चर्चा शुरू की, और क्यों उन्होंने जेएसएफ में जिस तरह से काम करना चाहते थे, उतना काम नहीं किया। विशेष मामला बूलियन गुणों के बारे में है।

। isUrl ग्रहण नाम के एक बूलियन संपत्ति के लिए यह

private boolean isUrl; 
public boolean isUrl() {..} 
public boolean setUrl(boolean url) {..} 

उत्पन्न करता है लेकिन इस JSF में काम नहीं करता। उन्होंने कहा कि यह public boolean getIsUrl() जोड़ने कार्यान्वयन गाड़ी हो सकता है द्वारा काम करते हैं, तो यकीन है कि जो सही है, इसके बाद के संस्करण कोड के लिए आत्मनिरीक्षण एपीआई .:

BeanInfo info = Introspector.getBeanInfo(ClassTest.class); 
for (PropertyDescriptor pd : info.getPropertyDescriptors()) { 
     System.out.println(pd.getName() + ": " + pd.getReadMethod() + 
     " : " + pd.getWriteMethod()); 
} 

का उपयोग करके, यह दोनों तरीकों प्रिंट करते हैं बनाया - यानी ग्रहण सही है, JSF गलत है। लेकिन यह मेरे लिए संदिग्ध लग रहा था, क्योंकि the specification डबल "है" के बारे में कुछ भी उल्लेख नहीं करता है।

लेकिन spec के माध्यम से देखते हुए, मैंने कुछ ऐसा देखा जो मैंने कभी नहीं उपयोग किया - तथाकथित अनुक्रमित गुण। आपके पास private String[] bar और फिर public String getBar(int idx) हो सकता है। तो:

। मैंने कोशिश की कि Introspector के साथ, और इसे बार के लिए पढ़ने की विधि नहीं मिली। उपरोक्त कोड का परिणाम था: bar: null : null। तो मुझे लगता था - अब इंट्रोस्पेक्टर spec का पालन नहीं करता है। शायद यह पिछले मामले में इसका पालन नहीं करता था, और आखिरकार, जेएसएफ सही है। वास्तव में, अनुक्रमित गुण ऐसा कर सकते हैं कि किसी दिए गए संपत्ति के लिए दो पढ़ने के तरीके हैं। और आत्मनिरीक्षण API के PropertyDescriptor वर्ग के साथ यह संभव नहीं है।

इससे हमें क्या कारण होता है - हमारे पास संभावित रूप से टूटा हुआ एपीआई है जो कल्पना के अनुरूप नहीं है। जो spec के अन्य कार्यान्वयन की ओर जाता है (जेएसएफ स्पष्ट रूप से एक कस्टम का उपयोग करता है)। जो आगे गलतफहमी और भ्रम की ओर जाता है।

मुझे परेशान करने वाली किसी चीज़ के लिए एक सिडेनोट - जावाबीन्स स्पेक में वे "डिजाइन पैटर्न" विधियों के लिए नामकरण सम्मेलन कहते हैं। यह मेरे लिए गलत लगता है।

तो, अब सवाल पर:

1. JavaBeans कल्पना स्पष्ट
2. है आत्मनिरीक्षण एपीआई सही
3. है एक नया JavaBeans विनिर्देश की जरूरत है, कम से कम बूलियन्स के व्यवहार को स्पष्ट करने का (जो एक हद तक व्यक्तिपरक)

अद्यतन। ऐसा लगता है कि जेएसएफ उपयोग bean.isUrlbean.url से अधिक है। जो दोषों को समझता है कि isUrl() एक्सेसर के साथ काम नहीं करना है।

पीएस जेडीके 1.6.0_20, जेएसएफ 1.2, माईफेसेस

Answer 1

जैसा कि @ पीटर लॉरी द्वारा उल्लिखित है, क्षेत्र का नाम जावाबीन के संबंध में अप्रासंगिक है। इसे अस्तित्व में भी नहीं होना चाहिए, या आप इसे एक मूर्ख नाम दे सकते हैं जैसे m_ के साथ उपसर्ग।

आपने bar संपत्ति के लिए उपयुक्त पढ़ने या लिखने के तरीके प्रदान नहीं किए हैं, इसलिए ये प्रदर्शित नहीं होने जा रहे हैं। आप रनटाइम पर मौजूदा कक्षा में Method संश्लेषित नहीं कर सकते हैं।मेरा मानना ​​है कि अनुक्रमित गुण देर से संस्करण थे, भले ही @since स्पष्ट नहीं है, इसलिए उनका उपयोग java.beans इंटरफेस द्वारा नहीं किया जाता है।

मेरे पास जेएसएफ स्पेक नहीं है (और यह jcp.org वकील दीवार के पीछे होगा), इसलिए यह नहीं पता कि यह क्या दावा करता है। यह JavaBeans spec [संभाव्य] के लिए कुछ अलग निर्दिष्ट कर सकता है, या आप बग के साथ कार्यान्वयन का उपयोग कर रहे हैं [मुझे लगता है कि भी संभावित]।

"डिजाइन पैटर्न" सिर्फ एक वाक्यांश है। हमारे डिजाइन में एक पैटर्न के रूप में होता है। यह गोफ में डिजाइन पैटर्न नहीं है।

Answer 2

जावा बीन गुण फ़ील्ड द्वारा नहीं, विधियों द्वारा परिभाषित किया गया है। इस कारण से PropertyDescriptor कक्षा में getReadMethod() और getWriteMethod() विधियां हैं, लेकिन getField() विधियां नहीं हैं।

व्यक्तिगत रूप से, मुझे लगता है कि आपका सहयोगी खराब अभ्यास का उपयोग कर रहा है।

ए) is एक क्रिया है। क्रियाओं के बाद फ़ील्ड का नाम नहीं होना चाहिए।

PropertyDescriptor pd; // let's assume this is set 
Method referenceMethod = pd.getReadMethod() == null 
    // at least one of these is not null 
    ? pd.getWriteMethod() : pd.getReadMethod(); 
Field underLyingField = referenceMethod 
          .getDeclaringClass() 
          .getDeclaredField(pd.getName()); 

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

उदा मैं अगर क्षेत्र एनोटेशन

---

अनुक्रमित प्रॉपर्टी के बारे में है की जाँच करने के ऊपर की तरह कोड का उपयोग करें:

आप सरणी या सूची (या नक्शा) संपत्तियों पर सूचकांक सिंटैक्स का उपयोग कर सकते हैं, लेकिन केवल अगर वे परिभाषित कर रहे हैं मानक बीन गुणों के रूप में।

तो तुम इस तरह एक संपत्ति है, तो:

private String[] bar; 
public String[] getBar(){ 
    return bar; 
} 
public void setBar(String[] bar){ 
    this.bar = bar; 
} 

या इस तरह:

private List<String> bar; 
public List<String> getBar(){ 
    return bar; 
} 
public void setBar(List<String> bar){ 
    this.bar = bar; 
} 

आप अभिव्यक्ति ${bar[0]}

साथ और एक नक्शे के संपत्ति के साथ पहले सदस्य का उपयोग कर सकते इस तरह:

private Map<String, String> bar; 
public Map<String, String> getBar(){ 
    return bar; 
} 
public void setBar(Map<String, String> bar){ 
    this.bar = bar; 
} 

आप इस ${bar['baz']} की तरह "baz" पर मैप किए गए मान तक पहुंच सकते हैं।

यह कार्यक्षमता मानक बीन्स कार्यक्षमता के शीर्ष पर बनाता है, इसलिए इसे नियमित गेटर्स/सेटर्स की आवश्यकता होती है।