फैक्ट्री विधि का डिज़ाइन पैटर्न कक्षाओं के होने और उन्हें व्यक्तिगत रूप से कॉल करने की तुलना में अधिक उपयोगी क्यों है?

Question

"गैंग ऑफ़ फोर" डिज़ाइन पैटर्न से, फ़ैक्टरी विधि है:

class Factory(product)
  case product
  when a
    new A
  when b
    new B
  when c
    new C
end

new Factory(a)

क्यों इस तीन वर्गों, की तुलना में अधिक उपयोगी है a, bऔर cऔर उन्हें अलग-अलग बुला?

Comments

तुम्हारा मतलब क्या है? तीनों को तत्काल क्यों नहीं? क्या यही मतलब है तुम्हारा?

— नील

@ नहीं, कारखाने के पैटर्न में सभी वर्ग भाई-बहन के रूप में मौजूद हैं। क्यों कारखाने को अप्रत्यक्ष रूप से ए, बी, सी कक्षाओं तक पहुंचने के लिए कहते हैं?

— alt

यह वास्तव में फैक्ट्री मेथड पैटर्न की तरह नहीं दिखता है, अगर एब्सट्रैक्ट फैक्ट्री के करीब कुछ भी

— jk।

क्योंकि डिज़ाइन के समय पर आपको पता नहीं होता है कि आपको किन 3 वर्गों की आवश्यकता है।

— MrWhite

@jk: नहीं, यह वास्तव में नहीं है। programmers.stackexchange.com/questions/81838/…

— pdr

Answer 1

क्योंकि आपका उदाहरण पर्याप्त जटिल नहीं है। इस तरह के एक सरल परिदृश्य के लिए यह भी एक उन्नत पैटर्न का उपयोग करने के लिए समझ में नहीं आता है।

लेकिन अगर आपको ए, बी या सी के निर्माण के लिए उत्पाद से अधिक जानना है, और आपके पास उस ज्ञान तक सीधी पहुंच नहीं हो सकती है, तो यह उपयोगी है। फिर आप आवश्यक वस्तुओं के उत्पादन के लिए ज्ञान केंद्र के रूप में कार्य करने के लिए कारखाने का उपयोग कर रहे हैं।

हो सकता है कि उन वस्तुओं को किसी वस्तु एक्स के संदर्भ की आवश्यकता हो, जिसे कारखाना प्रदान कर सकता है, लेकिन आपका कोड उस जगह पर है जहां आप ए, बी या सी का निर्माण करना चाहते हैं या एक्स तक पहुंच नहीं है या नहीं होना चाहिए। हो सकता है जब आपके पास एक्स हो। आप A और B बनाते हैं लेकिन यदि आपके पास Y प्रकार है तो आप C बनाते हैं।

यह भी विचार करें कि कुछ वस्तुओं को बनाने के लिए 20 निर्भरता की आवश्यकता हो सकती है; फिर क्या? एक जगह पर उन निर्भरता के लिए शिकार करने के लिए जाना जहां वे सुलभ नहीं होना चाहिए समस्याग्रस्त हो सकता है।

Comments

+1 यह स्पष्ट करने के लिए कि फ़ैक्टरी पैटर्न हमेशा सबसे अच्छा तरीका नहीं है।

— नील

क्योंकि आपका उदाहरण पर्याप्त जटिल नहीं है। इस तरह के एक सरल परिदृश्य के लिए यह भी एक उन्नत पैटर्न का उपयोग करने के लिए समझ में नहीं आता है। तो आप इस मामले में क्या करेंगे? सशर्त निर्माण को रेखांकित करें?

— पीडीआर

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

— मट्टुज़

पैटर्न को किसी कारण से फ़ैक्टरी विधि कहा जाता है। फैक्ट्री मेथड होने के लिए विधि का अलग वर्ग में होना आवश्यक नहीं है (हालाँकि यह अक्सर होता है)।

— पीडीआर

मैंने इसमें "मेथड" मिस किया है, इसलिए आप सही मिस्टर हैं।

— माटूसज

Answer 2

एक कारखाना पैटर्न आमतौर पर उससे अधिक जटिल होता है। एक कारखाना कुछ मानदंडों पर निर्णय लेता है जो बनाने / वापस करने के लिए उदाहरण देते हैं। इसके बजाय, जब आप कारखाने का उपयोग नहीं करते हैं, तो आप उस कोड को बार-बार अपने कोड में कई स्थानों पर उपयोग करते होंगे।

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

Answer 3

फ़ैक्टरी विधि पैटर्न कॉलिंग क्लास से निर्णय लेने की प्रक्रिया को रोक देता है। इसके कई फायदे हैं:

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

यूनिट Testability। मैं कारखाने के लिए 3 परीक्षण लिख सकता हूं, यह सुनिश्चित करने के लिए कि यह सही स्थितियों पर सही प्रकार लौटाता है, फिर मेरी कॉलिंग क्लास को केवल यह देखने के लिए परीक्षण करने की आवश्यकता है कि क्या यह कारखाने को कॉल करता है और फिर लौटे वर्ग पर आवश्यक तरीके। इसे कारखाने के कार्यान्वयन या ठोस वर्गों के बारे में कुछ भी जानने की जरूरत नहीं है।

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

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

जैसा कि कहा गया है, फ़ैक्टरी पैटर्न हमेशा जाने का रास्ता नहीं है। लेकिन, जहाँ भी आप सशर्त तात्कालिकता देखते हैं, आपको इसे एक पल का विचार देना चाहिए।

Answer 4

फैक्टरी पैटर्न के प्रमुख लाभ दो गुना हैं:

1. जिन स्थानों को उत्पाद के कार्यान्वयन की आवश्यकता होती है, उन्हें यह जानने की आवश्यकता नहीं है कि निर्माण कैसे किया जाए। कारखाना उस जानकारी को रखता है।

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

2. जिन स्थानों को उत्पाद के कार्यान्वयन की आवश्यकता होती है, उन्हें मॉड्यूल विवरण (यानी, संकलन समय पर) को जानने की आवश्यकता नहीं है कि कार्यान्वयन वर्ग का नाम क्या है।

   इस प्रकार, aकुछ भी करने की जरूरत नहीं है A; "क्या निर्माण करना है" वांछित गैर-कार्यात्मक गुणों के संदर्भ में वर्णित किया जा सकता है, और केवल नाम नहीं। यह बहुत अधिक लचीला है।

नकारात्मक पक्ष यह है कि जहां आप जानते हैं कि क्या बनाना है और इसे कैसे करना है, तो आप एक कारखाने का उपयोग करते समय अधिक जटिलता प्राप्त करते हैं। हालांकि यह तय करना आसान है: जब यह समझ में नहीं आता है तो एक कारखाने का उपयोग न करें!

Answer 5

मैं कक्षाओं के संदर्भ में डिजाइन पैटर्न के बारे में सोचना चाहता हूं जैसे कि 'लोग', और पैटर्न ऐसे तरीके हैं जिनसे लोग एक-दूसरे से बात करते हैं।

तो, मेरे लिए कारखाना पैटर्न एक भर्ती एजेंसी की तरह है। आपको कोई ऐसा व्यक्ति मिला है जिसे श्रमिकों की एक चर संख्या की आवश्यकता होगी। यह व्यक्ति कुछ ऐसी जानकारी को जान सकता है जिसकी उन्हें उन लोगों में आवश्यकता होती है जिन्हें वे किराए पर लेते हैं, लेकिन ऐसा है।

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

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

के सौजन्य से

Answer 6

फैक्ट्री पैटर्न सबसे ज्यादा इस्तेमाल की जाने वाली और गाली वाली डिजाइन पैटर्न है।

मैं कई मामलों में आया हूं, जहां एक फैक्ट्री क्लास को कोड किया जाता है जब एक साधारण कंस्ट्रक्टर पर्याप्त होगा।

जब तक एक कारखाना वर्ग का उपयोग न करें: -

• आप एक बाहरी संसाधन पर निर्भर करते हैं, लेकिन आप ठीक से नहीं जानते हैं कि कौन सा अभी तक है।
• निर्माण महंगा है और आप एक बार निर्माण करना चाहते हैं और कई बार पुन: उपयोग करते हैं।
• एक नई मिसाल का निर्माण करना इस बात पर निर्भर करता है कि पहले से क्या निर्माण किए गए हैं (जैसे कि आपके केवल पांच कनेक्शन हो सकते हैं, या, आपको उपयोग किए जाने वाले अंतिम नंबर की तुलना में एक कनेक्शन आईडी नंबर का उपयोग करना चाहिए)।

Answer 7

किसी उपवर्ग को इंस्टैंट करते समय फ़ैक्टरी विधि का उपयोग करें और ग्राहक कोड को यह तय करने के लिए ज़िम्मेदार नहीं माना जाता है कि कौन सा उपवर्ग तत्काल है।

यह उपयोगी है क्योंकि यह आपको क्लाइंट कोड को बदलने से रोकता है जब आपको यह बदलने की आवश्यकता होती है कि किस वर्ग को त्वरित रूप से मिलता है। मौजूदा कोड को बदलना बुरा अभ्यास है क्योंकि यह आमतौर पर त्रुटि प्रवण होता है।

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

यह आपके गधे को कवर करने का एक तरीका है, यदि आप अपने स्व-निर्माण में परिवर्तन कर सकते हैं कि कैसे या किस वर्ग में तात्कालिकता हो जाती है तो कारखाना वर्ग उपयोग करने के लिए समझ में आता है। यह आपकी कक्षाओं को उनकी एक जिम्मेदारी पर केंद्रित रखने में मदद करता है और परिणामस्वरूप यह सुनिश्चित करता है कि आपके पास मौजूदा कोड को संशोधित करने की संभावना कम है जो संबंधित नहीं है।