मैंने पहले के धागे में स्थिर वर्गों के अपने विचार लिखे :
मैं स्टैटिस्टिक मेथड से भरे यूटीलिटी क्लासेज से प्यार करता था। उन्होंने सहायक विधियों का एक बड़ा समेकन किया जो अन्यथा अतिरेक और रखरखाव नरक का कारण बन जाएगा। वे उपयोग करने के लिए बहुत आसान हैं, कोई तात्कालिकता नहीं, कोई निपटान नहीं, बस फायर'एन'फॉरगेट। मुझे लगता है कि यह एक सेवा उन्मुख वास्तुकला बनाने का मेरा पहला अनजाना प्रयास था - बहुत सारी स्टेटलेस सेवाएं जो सिर्फ अपना काम करती थीं और कुछ नहीं। हालाँकि सिस्टम बढ़ता है, ड्रेगन आ रहे हैं।
बहुरूपता
कहते हैं कि हमारे पास यूटिलिटीक्लास.सोममेथोड है जो खुशी से गूंजता है। अचानक हमें कार्यक्षमता को थोड़ा बदलने की जरूरत है। अधिकांश कार्यक्षमता समान है, लेकिन हमें कुछ हिस्सों को फिर भी बदलना होगा। अगर यह एक स्थैतिक विधि नहीं होती, तो हम एक व्युत्पन्न वर्ग बना सकते थे और आवश्यकतानुसार विधि सामग्री को बदल सकते थे। जैसा कि यह एक स्थिर विधि है, हम नहीं कर सकते। ज़रूर, अगर हमें पुरानी पद्धति से पहले या बाद में कार्यक्षमता को जोड़ने की आवश्यकता है, तो हम एक नया वर्ग बना सकते हैं और पुराने को इसके अंदर बुला सकते हैं - लेकिन यह सिर्फ स्थूल है।
इंटरफ़ेस मिटा देता है
तर्क कारणों के लिए इंटरफेस के माध्यम से स्थैतिक तरीकों को परिभाषित नहीं किया जा सकता है। और जब से हम स्थैतिक तरीकों को ओवरराइड नहीं कर सकते हैं, तब स्थिर कक्षाएं बेकार हो जाती हैं जब हमें उनके इंटरफ़ेस से उन्हें पास करने की आवश्यकता होती है। यह हमें एक रणनीति पैटर्न के हिस्से के रूप में स्थिर कक्षाओं का उपयोग करने में असमर्थ बनाता है। हम इंटरफेस के बजाय प्रतिनिधियों को पारित करके कुछ मुद्दों को पैच कर सकते हैं।
परिक्षण
यह मूल रूप से ऊपर उल्लेखित इंटरफ़ेस मुसीबतों के साथ हाथ में जाता है। जैसे-जैसे कार्यान्वयन को रोकना हमारी क्षमता बहुत सीमित है, हमें परीक्षण कोड के साथ उत्पादन कोड को बदलने में भी परेशानी होगी। फिर से, हम उन्हें लपेट सकते हैं, लेकिन इसके लिए हमें अपने कोड के बड़े हिस्सों को बदलने की आवश्यकता होगी, ताकि वास्तविक वस्तुओं के बजाय रैपर स्वीकार कर सकें।
फोस्टर खिलता है
जैसा कि स्थैतिक तरीकों को आमतौर पर उपयोगिता विधियों और उपयोगिता विधियों के रूप में उपयोग किया जाता है, आमतौर पर अलग-अलग उद्देश्य होंगे, हम जल्दी से गैर-सुसंगत कार्यक्षमता से भरे एक बड़े वर्ग के साथ समाप्त हो जाएंगे - आदर्श रूप से, प्रत्येक वर्ग का सिस्टम के भीतर एक ही उद्देश्य होना चाहिए। जब तक उनके उद्देश्यों को अच्छी तरह से परिभाषित किया जाता है तब तक मैं कक्षाओं के पांच गुना अधिक होता हूं।
पैरामीटर रेंगना
शुरू करने के लिए, उस छोटे से प्यारे और निर्दोष स्थिर तरीके से एक एकल पैरामीटर लिया जा सकता है। जैसे-जैसे कार्यक्षमता बढ़ती है, कुछ नए पैरामीटर जोड़े जाते हैं। जल्द ही आगे के पैरामीटर जोड़े जाते हैं जो वैकल्पिक होते हैं, इसलिए हम विधि का अधिभार बनाते हैं (या बस उन भाषाओं में डिफ़ॉल्ट मान जोड़ें, जो उनका समर्थन करते हैं)। लंबे समय से पहले, हमारे पास एक विधि है जो 10 पैरामीटर लेती है। केवल पहले तीन वास्तव में आवश्यक हैं, पैरामीटर 4-7 वैकल्पिक हैं। लेकिन अगर पैरामीटर 6 निर्दिष्ट किया गया है, तो 7-9 को भी भरे जाने की आवश्यकता है ... क्या हमने ऐसा करने के एकल उद्देश्य के साथ एक वर्ग बनाया था जो इस स्थिर विधि ने किया था, हम इसे आवश्यक मापदंडों में ले जाकर हल कर सकते हैं निर्माता, और उपयोगकर्ता को एक ही समय में कई अन्योन्याश्रित मूल्यों को सेट करने के लिए गुणों, या विधियों के माध्यम से वैकल्पिक मान सेट करने की अनुमति देता है। इसके अलावा,
उपभोक्ताओं को बिना किसी कारण वर्गों का एक उदाहरण बनाने की मांग करना
सबसे आम तर्कों में से एक है, क्यों मांग है कि हमारे वर्ग के उपभोक्ता इस एकल विधि को लागू करने के लिए एक उदाहरण बनाते हैं, जबकि बाद के उदाहरण के लिए इसका कोई उपयोग नहीं है? अधिकांश भाषाओं में कक्षा का एक उदाहरण बनाना बहुत सस्ता ऑपरेशन है, इसलिए गति कोई समस्या नहीं है। भविष्य में बहुत अधिक बनाए रखने योग्य समाधान की नींव रखने के लिए उपभोक्ता के लिए एक अतिरिक्त लाइन जोड़ना एक कम लागत है। और अंत में, यदि आप उदाहरणों को बनाने से बचना चाहते हैं, तो बस अपनी कक्षा का एक सिंगलटन रैपर बनाएं जो आसानी से पुन: उपयोग की अनुमति देता है - हालांकि इससे यह आवश्यक हो जाता है कि आपका वर्ग स्टेटलेस हो। यदि यह स्टेटलेस नहीं है, तो आप अभी भी स्थिर रैपर तरीके बना सकते हैं जो सब कुछ संभालते हैं, जबकि लंबे समय में आपको सभी लाभ प्रदान करते हैं। आखिरकार,
केवल एक सिथ निरपेक्षता में व्यवहार करता है
बेशक, मेरे स्थिर तरीकों को नापसंद करने के अपवाद हैं। ट्रू यूटिलिटी क्लासेस जो ब्लोट के लिए कोई जोखिम नहीं उठाती हैं, वे स्टैटिक तरीकों के लिए उत्कृष्ट मामले हैं- System.Convert एक उदाहरण के रूप में। यदि आपकी परियोजना भविष्य के रखरखाव के लिए कोई आवश्यकता नहीं है, तो समग्र वास्तुकला वास्तव में बहुत महत्वपूर्ण नहीं है - स्थिर या गैर स्थिर, वास्तव में कोई फर्क नहीं पड़ता - विकास की गति, हालांकि।
मानकों, मानकों, मानकों!
उदाहरण विधियों का उपयोग करना आपको स्थैतिक तरीकों का उपयोग करने से भी रोकता नहीं है, और इसके विपरीत। जब तक भेदभाव के पीछे तर्क है और यह मानकीकृत है। अलग-अलग कार्यान्वयन विधियों के साथ एक व्यापारिक परत को देखने से अधिक बुरा कुछ नहीं है।