एक कैच-ऑल ऐपटूलबॉक्स क्लास बनाना - क्या यह एक बुरा अभ्यास है?

Question

यकीन है कि कभी जहां जैसे कार्यों जगह:

String PrettyPhone(String phoneNumber) // return formatted (999) 999-9999 
String EscapeInput(String inputString) // gets rid of SQL-escapes like ' 

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

Answer 1

शानदार सवाल। मुझे हमेशा लगता है कि किसी भी पर्याप्त जटिल परियोजना को "उपयोगिता" कक्षाओं की आवश्यकता होती है। मुझे लगता है कि यह केवल इसलिए है क्योंकि ऑब्जेक्ट उन्मुख प्रोग्रामिंग की प्रकृति हमें चीजों को एक अच्छी तरह से संरचित पदानुक्रमित वर्गीकरण में रखने के लिए मजबूर करती है, जब यह हमेशा व्यवहार्य या उपयुक्त नहीं होती है (उदाहरण के लिए स्तनधारियों के लिए ऑब्जेक्ट मॉडल बनाने का प्रयास करें, और फिर प्लैटिपस को निचोड़ें)। यह समस्या है जो aspect oriented programming (सी.एफ. cross cutting concern) में काम को प्रेरित करती है। अक्सर उपयोगिता वर्ग में जो कुछ भी जाता है वह चीजें हैं जो क्रॉस-कटिंग चिंताओं हैं।

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

विषय पर मेरा अंतिम शब्द है: यदि आपको आवश्यकता हो तो इसके साथ जाएं, बस सुनिश्चित करें कि आप बेहतर डिज़ाइन को कम-से-कम नहीं कर रहे हैं। बेशक, यदि आपको आवश्यकता हो तो आप हमेशा बाद में प्रतिक्रिया दे सकते हैं।

Answer 2

इसमें कुछ भी गलत नहीं है। एक बात तार्किक भागों में इसे तोड़ने की कोशिश है। ऐसा करके आप अपने इंटेलिजेंस को साफ रख सकते हैं।

MyCore.Extensions.Formatting.People 
MyCore.Extensions.Formatting.Xml 
MyCore.Extensions.Formatting.Html 

Answer 3

मुझे लगता है कि कारण इस पर सिकोड़ी है क्योंकि "टूलबॉक्स" बढ़ सकता है और आप संसाधनों की एक टन हर बार जब आप एक भी समारोह कॉल करना चाहते हैं लोड हो रहा है हो जाएगा।

वास्तविक वर्ग में वस्तुओं पर लागू होने वाली विधियों के लिए यह और भी सुरुचिपूर्ण है - बस अधिक समझ में आता है।

कहा जा रहा है कि, मुझे व्यक्तिगत रूप से यह नहीं लगता कि यह एक समस्या है, लेकिन यह उपर्युक्त कारणों से केवल इससे बच जाएगी।

Answer 4

इन उदाहरणों में मैं और अधिक विस्तार करने के लिए इच्छुक हो जाएगा स्ट्रिंग:

class PhoneNumber extends String 
{ 
    public override string ToString() 
    { 
     // return (999) 999-9999 
    } 
} 

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

संपादित करें:

के रूप में नीचे ने कहा, आप सी # में स्ट्रिंग ओवरराइड नहीं कर सकते। बिंदु मैं बनाने की कोशिश कर रहा था कि इस कार्रवाई को इतना है कि वह जगह है जहाँ समारोह अंतर्गत आता है एक फोन नंबर पर किया जाता है:

interface PhoneNumber 
{ 
    string Formatted(); 
} 

आप विभिन्न स्वरूपों है, तो आप बयान करता है, तो के साथ अपने कोड कचरा बिना PhoneNumber के कार्यान्वयन की अदला-बदली कर सकते हैं उदाहरण के लिए,

बजाय:

if(country == Countries.UK) output = Toolbox.PhoneNumberUK(phoneNumber); 
else ph = Toolbox.PhoneNumberUS(phoneNumber); 

तुम बस का उपयोग कर सकते हैं:

output = phoneNumber.Formatted(); 

Answer 5

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

Answer 6

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

Answer 7

जब मैं एक आवेदन पत्र बनाने के लिए, मैं आम तौर पर एक स्थिर वर्ग है कि स्थिर तरीकों और गुण है कि मैं समझ नहीं सकता है, जहां कहीं भी डाल करने के लिए होता है पैदा करते हैं।

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

मैं इसे दूसरी तरह के कर की कोशिश की है, लेकिन दूसरी तरह के मूल रूप से एक ऑब्जेक्ट मॉडल लागू कर रहा है इससे पहले कि मैं अपने आवेदन ऑब्जेक्ट मॉडल ठीक से डिजाइन करने के लिए के बारे में जानना पर्याप्त है। अगर मैं कि करते हैं, मैं एक औसत दर्जे का समाधान मैं फिर से मिलना है और भविष्य में कुछ बिंदु पर जमीन से पुनर्निर्माण के लिए है के साथ आ समय और ऊर्जा भी पर्याप्त मात्रा में खर्च करते हैं। खैर, ठीक है, अगर मुझे पता है कि मैं इस कोड को दोबारा शुरू करने जा रहा हूं, तो मैं अनावश्यक जटिल वर्गों को डिजाइन करने और बनाने के चरण को कैसे छोड़ सकता हूं जो वास्तव में काम नहीं करते हैं?

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

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

बात यह है कि, जब मैंने पहली बार उस विधि को लागू किया (वास्तव में यह तीन या चार पारस्परिक तरीकों से था), मुझे पता चला कि यह सही जवाब नहीं था। लेकिन मुझे यह तय करने के लिए पर्याप्त जानकारी नहीं थी कि सही जवाब क्या था। इसलिए जब तक सही उत्तर स्पष्ट नहीं हुआ तब तक मैं सबसे सरल गलत जवाब के साथ गया।

Answer 8

मैंने एक टिप्पणी पोस्ट की, लेकिन सोचा कि मैं थोड़ा और विस्तार करूंगा।

मैं जो करता हूं वह नामस्थानों के साथ एक सामान्य पुस्तकालय बनाता है: [संगठन]। [उत्पाद]। रूट और उप नामस्थान हेल्पर्स के रूप में।

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

रूट नेमस्पेस में, आप उदाहरण उपयोगिता कक्षाओं का उपयोग कर सकते हैं जिन्हें राज्य की आवश्यकता होती है (वे मौजूद हैं!)। और कहने की जरूरत नहीं है कि उचित वर्ग का नाम भी इस्तेमाल करें, लेकिन हेल्पर से प्रत्यय न करें।