क्या आपके सॉफ़्टवेयर प्रोजेक्ट में "Utils" कक्षा होना अच्छा है?

Question

आमतौर पर, सॉफ्टवेयर विकास के दौरान, मुझे आवश्यक सभी प्रकार के उपयोगिता कार्यों की आवश्यकता होती है। ज़िपित फ़ाइल, निकालने ज़िप फ़ाइल, शुरू करने वेब ब्राउज़र की तरह, छवि बढ़ाया हो ...

मैं है कि क्या किया था, मैं "Utils"

https://github.com/yccheok/jstock/blob/master/src/org/yccheok/jstock/gui/Utils.java

नामक एक एकल वर्ग के भीतर स्थिर समारोह के रूप में सभी इस उपयोगिता कार्यों जगह

क्या यह एक अच्छा अभ्यास है? जब चीजें बड़ी और बड़ी हो जाती हैं तो चीजें अप्रबंधनीय हो जाएंगी?

Answer 1

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

उदाहरण के लिए, वेब एप्लिकेशन में आप इस तरह की पैकेज संरचना के साथ समाप्त हो सकते हैं।

org.sample.web.model 
org.sample.web.utils 
org.sample.web.validators 
org.sample.web.validators.utils 

Answer 2

मैं माइक की टिप्पणी से सहमत हूं। मैं सी # का उपयोग करता हूं, लेकिन इसी तरह के कार्यान्वयन। मेरे पास एक उपयोग प्रोजेक्ट है जो मैं गुप्त रूप से बनाए रखता हूं और फिर नई परियोजना में डीएलएल छोड़ देता हूं। इस तरह बग/परिवर्तन होते हैं, मैं बस डीएलएल को बदलकर परियोजनाओं को अद्यतन कर सकता हूं।

माइक ने अपनी टिप्पणी में सुझाव दिया है कि मैं आवेदन के विभिन्न क्षेत्रों के लिए एक अलग वर्ग रखता हूं।

Answer 3

हाँ, उपयोगिता वर्गों में एक अच्छा विचार कर रहे हैं लेकिन, सभी ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के साथ के रूप में, आप अधिकतम सामंजस्य, कम से कम युग्मन के लिए लक्ष्य होना चाहिए।

अधिकतम संयोजन का अर्थ है कि एक वर्ग में सबकुछ एक दूसरे से से भारी होना चाहिए। न्यूनतम युग्मन का मतलब है कक्षाओं के बीच कोई अनावश्यक निर्भरता नहीं होनी चाहिए।

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

ऐसा करना एक ईश्वर वस्तु के रूप में सिंगलटन पैटर्न का उपयोग करना है, एक यहूदी जहां आप बस अपने सभी बकवास को डंप करते हैं जो बेहतर संगठित होना चाहिए। मैं कहूंगा कि विकास के दौरान एक उबर-उपयोगिता वर्ग का उपयोग करना ठीक है लेकिन शिपिंग सुनिश्चित करने से पहले आपका कोड बेहतर व्यवस्थित है। रखरखाव बहुत आसान होगा।

क्या यह एक अच्छा अभ्यास है?

नहीं, लंबी अवधि में नहीं, हालांकि यह अस्थायी रूप से किया जाने पर उपयोगी है।

क्या चीजें बड़ी और बड़ी हो सकती हैं जब चीजें अप्रबंधनीय हो जाएंगी?

हां, इसके बारे में कोई सवाल नहीं है।

Answer 4

एक उपयोग वर्ग (या कक्षाओं का पैकेज) बहुत उपयोगी है। मैं आम तौर पर कक्षाओं में कार्यक्षमता से अपने यूटिल को अलग करता हूं, इसलिए मेरे पास फ़ाइल उपयोग, डेटाबेस उपयोग आदि हो सकता है।

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

Answer 5

मेरा अभ्यास *Utils क्लोज़ और *Helper कक्षाएं दोनों होना है। पूर्व में पुन: प्रयोज्य स्थिर कार्य (जावा और PHP के मामले में) हैं जो अनुप्रयोग-असंबंधित हैं, जहां उत्तरार्द्ध पुन: प्रयोज्य अनुप्रयोग/डोमेन तर्क - गैर स्थैतिक विधियां और आमतौर पर अन्य सेवाओं/बीन्स/प्रबंधकों के लिए निर्भरता के साथ होते हैं।

1. ही भाषा पहले से ही समर्थन करता है:

   ये कुछ नियम है कि मैं लागू करने से पहले मैं एक विधि या एक *Utils वर्ग बनाने के कर रहे हैं?

2. अपाचे कॉमन्स इसका समर्थन करता है? (या कुछ अन्य आम पुस्तकालय - क्योंकि किसी ने कुछ लिखा होगा जो आपके से बेहतर है)
3. मैं इसे पुन: प्रयोज्य (प्रोजेक्ट-/ऐप-तटस्थ) कैसे बना सकता हूं ताकि मेरी अन्य परियोजनाएं इसका उपयोग कर सकें?
4. मैं इसे कैसे नाम दूं? (हां, इसे हमेशा वर्गीकृत और अलग किया जाएगा, क्योंकि ये कक्षाएं अंततः बढ़ेगी और जब आप अधिक डेवलपर्स इसे और अधिक तरीके जोड़ते हैं तो आप उन पर नियंत्रण खो सकते हैं।)

Answer 6

उपयोगिता कक्षाएं आमतौर पर प्रक्रिया शैली कोड उत्पन्न करती हैं। शुद्ध ओओ सम्मेलनों के खिलाफ जाना। हालांकि, वे आपके जीवन को सरल बनाते हैं ताकि उनका उपयोग करें। लेकिन प्रत्येक व्यक्ति अपनी खुद की चीज करता है अन्यथा आप एक ईश्वर वर्ग के साथ समाप्त हो जाएंगे जो उन तरीकों के लिए एक पकड़ बन जाएगा जो उस वस्तु को फिट करने के लिए प्रतीत नहीं होते हैं जो उन्हें रहना चाहिए।

Answer 7

उपयोगिता को तोड़ना एक अच्छा तरीका है। आम तौर पर आप अपने वर्गों को ब्लब्स में बदलने से बचना चाहते हैं।

http://sourcemaking.com/antipatterns/the-blob

Answer 8

यह एक अच्छा अभ्यास है?

ज्यादातर मामलों में, मैं इस तरह से उपयोग करता हूं।

सभी ऑब्जेक्ट उन्मुख प्रोग्रामिंग के साथ, आपको अधिकतम समेकन, न्यूनतम युग्मन के लिए लक्ष्य बनाना चाहिए।

उन नियमों का सख्ती से पालन करके अपनी उत्पादकता को मत मारो, आप वहां से कई महान ढांचे को तोड़ सकते हैं।

Answer 9

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

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

Answer 10

यदि यह कम से कम स्थिर है, तो यह Util कक्षा में समझ में आता है। यह आसान है! एकजुटता और युग्मन आपके जीवन को बनाने के लिए हैं आसान, यह एक स्पष्ट स्थिति है जिसमें वे नहीं करेंगे, इसलिए मैं इसे अपना रास्ता बनाए रखने का सुझाव दूंगा।

Answer 11

दरअसल, Utils और Helper कक्षाओं की अवधारणा वातावरण में नि: शुल्क कार्यों को लिखने में असमर्थता से आती है जहां प्रत्येक कार्य को कक्षा (या तो भाषा या परियोजना प्रतिबंधों के कारण) के स्वामित्व की आवश्यकता होती है। Utils वर्ग स्थिर कार्य के अलावा कुछ भी नहीं, मुक्त कार्यों के साथ एक पैकेज की भूमिका अभिनय समाप्त होता है।

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