फैक्टरी पैटर्न: एक बीन (गुइस/अमरूद) बनाते समय इनपुट को मान्य करना

Question

मैं निर्भरता इंजेक्शन के लिए गुइस का उपयोग करके एक नया ऐप लिख रहा हूं, और विशेषता सत्यापन के लिए अमरूद की पूर्व शर्त।

मैं बाहरी इनपुट के आधार पर सेम बनाने के लिए कारखाने पैटर्न का उपयोग कर रहा हूं। सवाल यह है कि, इनपुट को प्रमाणित करने का पसंदीदा तरीका क्या होगा? (रख-रखाव, स्पष्टता, आदि के संदर्भ में)

के इन कक्षाओं मान लेते हैं:

Bean.java

public interface Bean { 

    public Object getFoo(); 

} 

BeanImpl.java

public class BeanImpl implements Bean { 

    private final Object foo; 

    public BeanImpl(Object param) { 
     foo = param; 
    } 

    @Override 
    public String getFoo() { 
     return foo; 
    } 

} 

मैं यह देखना चाहते हैं कि "param" के लिए "foo" का वैध मान है:

Preconditions.checkArgument(SomeValidator.isValid(param), "Bad param: %s!", param); 

मुझे यह कहां करना चाहिए और क्यों?

• बीनइम्पल के निर्माता में? (मुझे यकीन नहीं है कि क्यों कन्स्ट्रक्टर में चेक जोड़ना एक बुरा विचार है।)
• BeanFactory.create (param) को कॉल करने से पहले? (भयानक कोड डुप्लिकेशन की तरह लगता है।)
• कुछ गिसिस तंत्र के माध्यम से मुझे अनजान है?

Answer 1

यदि यह कभी एक विशेष foo मूल्य के साथ एक BeanImpl के निर्माण के लिए अमान्य है, तो ब्यौरा क्या गलत है निर्माता में एक IllegalArgumentException फेंक देते हैं।

public class BeanImpl { 
    ... 
    public BeanImpl(Object param) { 
    if (param == null) { 
     throw new IllegalArgumentException("Param cannot be null"); 
    } 
    foo = param; 
    } 
    ... 
} 

वस्तुओं "राज्य और संयुक्त व्यवहार" होने की जल्दी परिभाषाओं से यह लागू करता है कि अवैध राज्य के साथ अपनी वस्तुओं को प्रदूषित नहीं है।

कारखाने तक, वस्तुओं का निर्माण करने से पहले मूल्यों की जांच करना एक सुविधा है, लेकिन कारखाने की वास्तविक जिम्मेदारियां वस्तु की जिम्मेदारियों में विस्तार नहीं करती हैं। कारखाना पैटर्न यह सुनिश्चित करने के लिए अच्छा है कि एक वस्तु सार्थक तरीकों से दूसरों से मेल खाती है, लेकिन ऑब्जेक्ट का आंतरिक राज्य सही है यह सुनिश्चित करने के लिए ऑब्जेक्ट का काम नहीं करना चाहिए।

एक ऑब्जेक्ट (कारखाना) होने के बाद यह सुनिश्चित करना कि एक और वस्तु का राज्य सही है, गलत व्यवहार है। आपने कारखाने में व्यवहार (सत्यापन राज्य) रखा है, लेकिन राज्य वस्तु में है। नतीजतन, अब आपके पास विकेन्द्रीकृत कनेक्टेड कोड है जो कसकर युग्मित होना चाहिए। इसका मतलब यह है कि अब जब आप समझ में आते हैं तो ऑब्जेक्ट बनाने के लिए फैक्ट्री रखने के बजाय, ऑब्जेक्ट बनाने के लिए आपको एक फैक्ट्री रखना होगा, और ऑब्जेक्ट को सीधे तब नहीं करना चाहिए जब यह नहीं होता है।

यह अक्सर यूनिट परीक्षण में आता है। यदि आपने फैक्ट्री में सत्यापन कोड नहीं रखा है, तो आप ऑब्जेक्ट को स्वतंत्र रूप से ऑब्जेक्ट का परीक्षण कर सकते हैं; खराब पैरामीटर के लिए परीक्षण। हालांकि, अगर आप कारखाने में सत्यापन कोड डालते हैं, तो आप फैक्ट्री के बिना "वैध" ऑब्जेक्ट्स बनाने में सक्षम नहीं होंगे, जो पहला संकेत है कि आप पाएंगे कि आपने अनैसर्गिक रूप से दो वस्तुओं को जोड़ा है जिन्हें कसकर एक साथ जोड़ना नहीं चाहिए ।

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

Answer 2

Netflix से बाहर Guvernator ढांचे की जांच:

https://github.com/Netflix/governator/wiki/Field-Validation

यह गूगल Guice पर निर्माण और जैसे कुछ शांत कार्यक्षमता के साथ यह विस्तार है

• lifecycles (निर्माण, validaiton, वार्मअप, नष्ट)
• सत्यापन
• कॉन्फ़िगरेशन

आपकी परियोजना में गुफागार शामिल करने के लिए थोड़ा और बॉयलर प्लेट है, लेकिन निश्चित रूप से यह प्रयास करने योग्य है।