वर्तमान में मैंने एक एबीसी फैक्ट्री क्लास बनाया है जिसमें एबीसी ऑब्जेक्ट्स बनाने का एक तरीका है। अब जब मैं इसके बारे में सोचता हूं, शायद कारखाने के बजाय, मैं सिर्फ अपने एबीसी विधि में एक स्थिर विधि बना सकता हूं। इस परिवर्तन को करने के लिए प्रो और कॉन क्या हैं? क्या इसका नेतृत्व नहीं होगा? मुझे उम्मीद है कि अन्य वर्गों को एबीसी का वारिस नहीं है, लेकिन कोई कभी नहीं जानता!किस मामले में स्थिर कार्यों के बजाय कारखाने वर्गों का उपयोग करना समझ में आता है?
धन्यवाद
असल में, यदि आप फैक्ट्री क्लास के लाभ प्राप्त करना चाहते हैं, तो आपको अपनी कक्षा में स्थिर विधि की आवश्यकता है। यह आपको बाद में नए कारखाने के वर्ग बनाने, या मौजूदा व्यवहार को अलग-अलग व्यवहार करने के लिए पुन: कॉन्फ़िगर करने की अनुमति देगा। उदाहरण के लिए, एक कारखाना वर्ग यूनिकॉर्न्स बना सकता है जो IFourHoovedAnimal इंटरफेस को कार्यान्वित करता है। आपके पास एक एल्गोरिदम लिखा हो सकता है जो IFourHoovedAnimal के साथ चीजें करता है और उन्हें तुरंत चालू करने की आवश्यकता होती है। बाद में आप एक नया कारखाना वर्ग बना सकते हैं जो इसके बजाय पेगासस को तुरंत चालू करता है जो IFourHoovedAnimal को भी कार्यान्वित करता है। पुराना एल्गोरिदम अब नए कारखाने का उपयोग कर पेगासस के लिए पुन: उपयोग किया जा सकता है! इस काम को बनाने के लिए पेगासस फैक्ट्री और यूनिकॉर्न फैक्ट्री को कुछ सामान्य बेस क्लास (आमतौर पर एक अमूर्त वर्ग) से प्राप्त होना चाहिए।
तो आप स्थैतिक विधि को अपने कारखाने वर्ग में रखकर देखते हैं, आप पुरानी एल्गोरिदम का पुन: उपयोग करने के लिए नए लोगों के साथ कारखाने के वर्गों को स्वैप कर सकते हैं। यह टेस्टेबिलिटी में सुधार के लिए भी काम करता है, क्योंकि अब इकाई परीक्षणों को कारखाने को खिलाया जा सकता है जो नकली वस्तुओं को बनाता है।
मैंने बहुत छोटी परियोजनाओं के लिए बाद में (कक्षा में स्थैतिक फैक्ट्री विधि जिसे आप बना रहे हैं) कर चुके हैं, लेकिन ऐसा इसलिए था क्योंकि मुझे कुछ पुराने कोड को दोबारा सुधारने में मदद करने के लिए इसकी आवश्यकता थी, लेकिन न्यूनतम में परिवर्तन रखना । असल में उस मामले में मैंने कोड का एक हिस्सा बनाया था जिसने एएसपी.NET नियंत्रणों का एक समूह बनाया, और उन सभी नियंत्रणों को उपयोगकर्ता नियंत्रण में रख दिया। मैं अपनी नई उपयोगकर्ता नियंत्रण संपत्ति को आधारित बनाना चाहता था, लेकिन पुराने विरासत कोड के लिए पैरामीटर आधारित कन्स्ट्रक्टर के साथ उपयोगकर्ता नियंत्रण बनाने के लिए यह आसान था।
इसलिए मैंने एक स्थिर फैक्ट्री विधि बनाई जो सभी मानकों को ले गया, और उसके बाद उपयोगकर्ता नियंत्रण को स्थापित किया और पैरामीटर के आधार पर इसकी गुणों को सेट किया। पुराने विरासत कोड ने उपयोगकर्ता नियंत्रण बनाने के लिए इस स्थिर विधि का उपयोग किया, और भविष्य कोड इसके बजाय "सुंदर" गुणों का उपयोग करेगा।
ठोस वर्ग के लिए, कारखाने तरीकों वास्तव में सिर्फ वास्तविक प्रकार (जो कहने के लिए वे उपयोगी नहीं हैं नहीं है बनाने अविवेक के आसपास की एक विधि है, लेकिन जैसा कि आप मिल गया है, कारखाने विधि वास्तव में कहीं भी हो सकता है)।
जहां फैक्ट्री विधि वास्तव में चमकती है, तब भी जब आपकी विधि किसी इंटरफ़ेस प्रकार के उदाहरण बनाती है।
एक एकल होने के बाद, स्थैतिक विधि परीक्षण करने के लिए और अधिक कठिन बनाती है जबकि एक तत्काल वस्तु होने से यह परीक्षण करना आसान हो जाता है। इसके अलावा, निर्भरता इंजेक्शन बाद में गैर स्थैतिक समाधान के साथ एक विकल्प के अधिक है।
बेशक, यदि आपको इनमें से किसी की आवश्यकता नहीं है, तो ये अच्छे तर्क नहीं हैं।
फैक्टरी विधि का मुख्य लाभ एक इंटरफेस के पीछे एक विशिष्ट वर्ग के संदर्भ को छिपाने की क्षमता है। चूंकि स्थैतिक विधियां इंटरफ़ेस का हिस्सा नहीं हो सकती हैं, इसलिए स्थैतिक फैक्ट्री विधियां मूल रूप से कन्स्ट्रक्टर विधि के समान होती हैं। स्थैतिक फैक्ट्री विधियों का एकमात्र उपयोगी अनुप्रयोग एक निजी कन्स्ट्रक्टर तक पहुंच प्रदान करना है - आमतौर पर सिंगलटन-पैटर्न कार्यान्वयन के लिए उपयोग किया जाता है।
+1 छोटा और स्पष्ट। –
Uncle Bob's SOLID Principles of Object Oriented Design में "डी" "निर्भरता इनवर्जन प्रिसिपल" विवेकानुसार नहीं, अवशेषों पर निर्भर करता है।
उस सिद्धांत के एक चरम अनुवर्ती में आपकी मुख्य कक्षाएं आपके कारखानों को बना सकती हैं, प्रत्येक फैक्ट्री इंटरफेस के माध्यम से अन्य कारखानों का उपयोग करके। "नई" (कंक्रीट ऑब्जेक्ट्स बनाने) की एकमात्र उपस्थिति आपके मुख्य वर्ग और आपके कारखानों में होगी। आपूर्ति की गई फैक्ट्री कार्यान्वयन से प्राप्त ठोस निर्भरताओं के साथ, आपकी सभी वस्तुएं इंटरफेस (अबास्ट्रक्शन) के साथ काम करती हैं।
आप फिर आसानी से समायोजित कर सकते हैं, या विभिन्न परिदृश्यों के लिए अनुकूलित कई मुख्य वर्ग प्रदान कर सकते हैं।
डिज़ाइन पैटर्न का अत्यधिक उपयोग खतरनाक है, और रचनात्मक डिज़ाइन पैटर्न समझ में आते हैं जब आपके पास परिभाषित इंटरफेस के साथ श्रेणी पदानुक्रम होते हैं, या जटिल वस्तुओं को बनाने की आवश्यकता होती है। यदि आपके पास एक साधारण डिज़ाइन है, तो सरल समाधान का उपयोग करें। इसलिए, आपके मामले में, फैक्टरी विधि पर्याप्त होगा
हाँ, तुम ठीक कह रहे हैं, यह है एक और डिजाइन पैटर्न :)
क्यों यह एक गैर स्थिर विधि के साथ आसान परीक्षण करने के लिए है? –
@devoured elysium: उदाहरण के लिए, एक टेस्ट क्लास में मूल का उप-वर्ग शामिल हो सकता है जो विधि को ओवरराइड करता है, उपकरण या शॉर्ट सर्किटिंग सामान्य व्यवहार के लिए। यह एक स्थिर विधि के साथ (आसानी से) संभव नहीं है। –
@devoured elysium - क्योंकि आप टेस्ट विधियों (कम से कम अच्छी तरह से नहीं) के पैरामीटर के रूप में एक स्थिर वर्ग को पारित नहीं कर सकते हैं। यह निर्भरता इंजेक्शन के बारे में दूसरे बिंदु से संबंधित है। लेकिन, जैसा कि जैक्सिडियन ने कहा, ये अंक महत्वपूर्ण नहीं हो सकते हैं। –