2015-10-02 7 views
5

हाल ही में मैं एक निर्माता पैटर्न के साथ आया जिसने मुझे चिढ़ाया।बिल्डरपटर के अंदर तर्क

तो, मेरे पास EntityBuilder है जो Entity बनाता है, लेकिन यह इकाई को वापस नहीं करता है।

public void build(); 

इसके बजाय, build() विधि के अंदर, यह बनाई गई नई वस्तु, Entity बचाता है, एक CacheImplementation उदाहरण यह स्टोर करने के लिए करने के लिए: यहाँ विधि हस्ताक्षर है। नोट: CacheImpl बिल्डर के निर्माता में इंजेक्शन दिया गया है।

public void build(){ 
    //create new entity 
    cacheImplementation.add(entity); 
} 

क्या यह सर्वोत्तम अभ्यास की तरह लगता है?

बाद में संपादित करें 0

public interface EntityBuilder { 

    void setProperty0(PropertyObject propertyObject0); 
    void setProperty1(PropertyObject propertyObject1); 
    void setProperty2(PropertyObject propertyObject2); 
    //... 

    void build(); 
} 

public class EntityBuilderImpl implements EntityBuilder { 

    PropertyObject propertyObject0; 
    PropertyObject propertyObject1; 
    PropertyObject propertyObject2; 
    //... 

    // setters for all properties 
    @Override 
    public void build(){ 
     //create new entity 
     cacheImplementation.add(entity); 
    } 
} 

बिल्डर का प्रयोग इस प्रकार है:

public class EntityProcessor{ 
    private EntityBuilderFactory entityBuilderFactory;//initialized in constructor 

    void process(EntityDetails entityDetails){ 
     EntityBuilder entityBuilder = this.entityBuilderFactory.getNewEntitytBuilder(); 
     //.. 
     // entityBuilder.set all properties from entityDetails 
     entityBuilder.build(); 
    } 
} 

नोट: cacheImpl उदाहरण सिर्फ एक List<> है जिसमें संस्थाओं संग्रहीत करता है हर एन सेकंड तक पहुँचता है।

उत्तर

2

क्या यह सर्वोत्तम अभ्यास की तरह लगता है?

पारंपरिक निर्माता पैटर्न कहीं भी बनाई गई वस्तु को संग्रहीत नहीं करता है, यह बस इसे वापस देता है।

मैं एक भिन्नता की कल्पना कर सकता हूं जहां निर्माता के पास डुप्लिकेट ऑब्जेक्ट्स बनाने और अपरिवर्तनीय वस्तुओं की एक दुकान का प्रबंधन करने के लिए इंस्टेंस नियंत्रण की भूमिका भी है।

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

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

+0

पारंपरिक डिजाइन पैटर्न के बदलाव अच्छे लगते हैं। मैंने यह देखने के लिए कोड का एक छोटा सा स्निपेट जोड़ा है जिसका मेरा मतलब है। क्या यह न्याय करने के लिए पर्याप्त है? – VladLucian

+0

नहीं, पर्याप्त नहीं है। अधिक दिलचस्प हिस्सा बिल्डर और कैश का उपयोग होगा। एक कैश के रूप में एक सूची बीटीडब्ल्यू अजीब लगता है। मुझे एक नक्शा की उम्मीद थी। – janos

+0

यह एक सूची नहीं है, यह प्रसंस्करण शुरू होने पर हर बार, एन सेकंड पर एक सेट साफ़ किया जाता है। मैंने फिर से संपादित किया है कि निर्माता का उपयोग कैसे किया जाता है। – VladLucian

0

मैंने JCodeModel कक्षा में समान void build() विधि देखी है। आप देख सकते हैं यह IOException फेंकता resources it manages की वजह से:

public void build(File destDir, 
        PrintStream status) 
      throws IOException 

आप मूल रूप से आप के लिए प्रक्रिया निष्पादित करने के यह पूछने के लिए और यदि कोई त्रुटि मौजूद है - आप वर्कफ़्लो के साथ जारी रख सकते हैं।

+0

@Vlad अगर आप "धन्यवाद" टिप्पणी को हटा दें तो यह अच्छा होगा। उपयोगी उत्तरों के लिए साइट नीति उनको वोट दे रही है। आइए इसे साफ रखें। मैं बाद में इस टिप्पणी को भी हटा दूंगा। – ekostadinov

0

सामान्य निर्माता में निम्न तरीके से उपयोग किया जाता है: कुछ कक्षा कक्षा बनाने के लिए निर्माता का उपयोग करेगी। कैशिंग - सरल

enter image description here


अब आप जटिलता के अतिरिक्त टुकड़ा है। आप बिल्डर के अंदर कैशिंग या प्रोसेसर के अंदर एक स्तर ऊपर रख सकते हैं।

क्या बिल्डर के अंदर कैश प्रबंधन डालने के निहितार्थ हैं:

  • बिल्डर एकल जिम्मेदारी अब और नहीं है।
  • यह कैसे आप पहली नजर में उम्मीद करेंगे काम नहीं करता है
  • आप इसे कैश

इन समस्याओं घटित नहीं होगा यदि आप अलग वर्ग के लिए कैश प्रबंधन डाल में डाले बिना वस्तु बनाने में असमर्थ हैं।


मैं कहूंगा कि यह भयानक समाधान नहीं है, लेकिन यह निश्चित रूप से आपके कोड की रखरखाव को कम करेगा।

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