software - java verify




क्या आपके सॉफ्टवेयर प्रोजेक्ट में "यूटिल्स" क्लास होना अच्छा है? (8)

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

मैंने जो कुछ किया है, मैं इस सभी उपयोगिता कार्यों को "यूटिल्स" नामक एकल वर्ग के भीतर स्थिर कार्य के रूप में रखता हूं

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

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


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

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

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

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


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

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

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

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

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


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

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


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

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


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

ये कुछ नियम हैं जो मैं एक विधि या एक *Utils श्रेणी बनाने से पहले लागू करता हूं:

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

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


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

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

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

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

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

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

क्या कार्यों की संख्या बड़ी और बड़ी होने पर असहनीय चीजें बढ़ेंगी?

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





java