वर्ग डिजाइन: क्या अच्छा है?

डेनिस Tsyplakov , समाधान वास्तुकार, DataArt द्वारा पोस्ट किया गया

वर्षों से, मैंने पाया है कि प्रोग्रामर समय-समय पर वही गलतियाँ दोहराते हैं। दुर्भाग्य से, विकास के सैद्धांतिक पहलुओं पर किताबें उनसे बचने में मदद नहीं करती हैं: किताबें आमतौर पर ठोस, व्यावहारिक सलाह नहीं होती हैं। और मुझे भी लगता है कि क्यों ...

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

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

लक्ष्य आवेदन

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

• जिस समय प्रोसेसर एक अनुरोध को संसाधित करने में खर्च करता है वह महत्वपूर्ण है, लेकिन महत्वपूर्ण नहीं है - मौसम में 0.1% की वृद्धि नहीं होगी।
• हमारे निपटान में मेमोरी के कोई टेराबाइट्स नहीं हैं, लेकिन यदि एप्लिकेशन अतिरिक्त 50-100 Kbytes लेता है, तो यह एक आपदा नहीं होगी।
• बेशक, शुरुआत का समय जितना कम होगा, उतना अच्छा होगा। लेकिन 6 सेकंड और 5.9 सेकंड के बीच कोई बुनियादी अंतर नहीं है।

अनुकूलन मानदंड

इस मामले में हमारे लिए क्या महत्वपूर्ण है?

प्रोजेक्ट कोड का उपयोग व्यवसाय द्वारा कई के लिए किया जा सकता है, शायद दस साल से अधिक।

अलग-अलग समय पर कोड कई डेवलपर्स द्वारा एक दूसरे के साथ अपरिचित द्वारा संशोधित किया जाएगा।
यह संभव है कि कुछ वर्षों में, डेवलपर्स नई LibXYZ लाइब्रेरी या FrABC ढांचे का उपयोग करना चाहेंगे।

कुछ बिंदु पर, कोड या संपूर्ण परियोजना का हिस्सा किसी अन्य परियोजना के कोड आधार के साथ विलय किया जा सकता है।

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

हम वर्ग डिजाइन से क्या चाहते हैं

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

• मैं एक डेवलपर को पसंद करूंगा जो एप्लिकेशन कोड से पूरी तरह परिचित न हो, यह समझने में सक्षम हो कि यह क्लास एक क्लास को देखते समय क्या कर रहा है। और इसके विपरीत - एक कार्यात्मक या गैर-कार्यात्मक आवश्यकता को देखते हुए, मैं जल्दी से अनुमान लगा सकता हूं कि आवेदन इसके लिए जिम्मेदार कक्षाओं में कहां स्थित है। खैर, यह वांछनीय है कि आवश्यकताओं का कार्यान्वयन पूरे आवेदन में "फैल" नहीं है, लेकिन एक वर्ग या कक्षाओं के एक कॉम्पैक्ट समूह में केंद्रित है। मुझे एक उदाहरण के साथ समझाते हैं कि मैं किस तरह के एंटीपैटर्न का मतलब है। मान लें कि हमें यह सत्यापित करने की आवश्यकता है कि एक निश्चित प्रकार के 10 अनुरोध केवल उन उपयोगकर्ताओं द्वारा निष्पादित किए जा सकते हैं जिनके खाते में 20 से अधिक अंक हैं (इसका कोई मतलब नहीं है)। ऐसी आवश्यकता को लागू करने का एक बुरा तरीका प्रत्येक अनुरोध की शुरुआत में एक चेक सम्मिलित करना है। फिर तर्क को 10 तरीकों में फैलाया जाएगा, विभिन्न नियंत्रकों में। एक अच्छा तरीका एक फ़िल्टर या WebRequestInterceptor बनाना और एक जगह सब कुछ जांचना है।
• मैं चाहता हूं कि एक वर्ग में परिवर्तन प्रभावित न करने के लिए वर्ग अनुबंध को प्रभावित न करे, या, (चलो यथार्थवादी हो!) कम से कम बहुत अधिक वर्गों को प्रभावित न करें। दूसरे शब्दों में, मैं एक वर्ग अनुबंध के कार्यान्वयन को संक्षिप्त करना चाहता हूं।
• मैं चाहूंगा कि यह संभव हो, जब क्लास कॉन्ट्रैक्ट को बदलकर, कॉल्स की श्रृंखला के माध्यम से जाकर और यूज़ेज को खोजकर, उन क्लासेस को खोजें जो इस बदलाव को प्रभावित करते हैं। यही है, मैं चाहता हूं कि कक्षाओं में कोई अप्रत्यक्ष निर्भरता न हो।
• यदि संभव हो तो, मैं यह देखना चाहूंगा कि कई एकल-स्तरीय चरणों से मिलकर अनुरोध प्रक्रिया प्रक्रियाएँ कई वर्गों के कोड द्वारा स्मियर नहीं की जाती हैं, लेकिन एक ही स्तर पर वर्णित हैं। यह बहुत अच्छा है अगर इस तरह की प्रसंस्करण प्रक्रिया का वर्णन करने वाला कोड स्पष्ट नाम के साथ एक विधि के अंदर एक स्क्रीन पर फिट बैठता है। उदाहरण के लिए, हमें एक पंक्ति में सभी शब्दों को खोजने की जरूरत है, प्रत्येक शब्द के लिए एक तृतीय-पक्ष सेवा को कॉल करें, शब्द का विवरण प्राप्त करें, विवरण के लिए प्रारूपण लागू करें और डेटाबेस में परिणाम सहेजें। यह 4 चरणों में क्रियाओं का एक क्रम है। कोड को समझने और उसके तर्क को बदलने के लिए बहुत सुविधाजनक है जब कोई विधि होती है जहां ये चरण एक के बाद एक होते जाते हैं।
• मैं वास्तव में कोड में समान चीजों को उसी तरह से लागू करना चाहता हूं। उदाहरण के लिए, यदि हम कंट्रोलर से तुरंत डेटाबेस एक्सेस करते हैं, तो हर जगह ऐसा करना बेहतर होता है (हालांकि मैं इस तरह के डिजाइन को अच्छा अभ्यास नहीं कहूंगा)। और अगर हम पहले ही सेवाओं और रिपॉजिटरी के स्तरों में प्रवेश कर चुके हैं, तो डेटाबेस से सीधे नियंत्रक से संपर्क न करना बेहतर है।
• मैं चाहूंगा कि बहुत अधिक न होने के लिए कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के लिए सीधे जिम्मेदार वर्ग / इंटरफेस की संख्या न हो। एक ऐसी परियोजना के साथ काम करना जिसमें तर्क के साथ प्रत्येक वर्ग के लिए दो इंटरफेस हों, पाँच वर्गों, एक वर्ग कारखाने और एक सार वर्ग कारखाने से विरासत का एक जटिल पदानुक्रम, काफी मुश्किल है।

व्यावहारिक सिफारिशें

तैयार की गई इच्छाओं के बाद, हम उन विशिष्ट चरणों की रूपरेखा तैयार कर सकते हैं जो हमें अपने लक्ष्यों को प्राप्त करने की अनुमति देंगे।

स्थैतिक तरीके

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

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

उसी समय, IoC डिब्बे की तुलना में स्थैतिक तरीके विधि आह्वान की गति में बहुत ही महत्वहीन लाभ देते हैं। और इस पर, शायद, फायदे समाप्त हो जाते हैं।

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

यहां पाठक पूछ सकता है: "लेकिन स्ट्रिंगरटिल्स और आईओयूटीइल्स कक्षाओं के बारे में क्या?" दरअसल, जावा दुनिया में एक परंपरा विकसित हुई है - स्ट्रिंग्स और इनपुट-आउटपुट धाराओं के साथ काम करने के लिए सहायक कार्यों को स्थैतिक तरीकों से जोड़ने के लिए और उन्हें SomeUtils वर्गों की छतरी के नीचे इकट्ठा करने के लिए। लेकिन यह परम्परा मुझे नहीं बल्कि गन्दी लगती है। यदि आप इसका पालन करते हैं, तो निश्चित रूप से, बहुत नुकसान की उम्मीद नहीं है - सभी जावा प्रोग्रामर इसका उपयोग करते हैं। लेकिन इस तरह के कर्मकांड में कोई समझदारी नहीं है। एक ओर, क्यों न स्ट्रींगयूलेट्स बीन बनाया जाए, दूसरी ओर, यदि आप बीन और सभी सहायक विधियों को स्थिर नहीं बनाते हैं, तो पहले से ही स्टैटिक छाता क्लासेस StockTradingUtils और BlockChainUtils करें। तर्क को स्थिर तरीकों में डालना शुरू करना, एक सीमा खींचना और रोकना मुश्किल है। मैं आपको सलाह देता हूं कि आप शुरू न करें।

अंत में, यह मत भूलो कि जावा 11 में कई सहायक विधियां जो दशकों से परियोजना के लिए डेवलपर्स को भटक ​​रही थीं, या तो मानक पुस्तकालय का हिस्सा बन गईं, या पुस्तकालयों में विलय हो गईं, उदाहरण के लिए, Google अमरूद में।

परमाणु, कॉम्पैक्ट क्लास अनुबंध

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

दूसरी ओर, बहुत छोटी कक्षाएं न बनाएं, जिनमें से प्रत्येक को एक कार्रवाई के लिए डिज़ाइन किया गया है। लेकिन तब वर्ग किस आकार का होना चाहिए? मूल नियम इस प्रकार हैं:

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

यह नियम क्यों महत्वपूर्ण है?

• सबसे पहले, अपने आप को स्पष्ट रूप से समझाने की क्षमता कि प्रत्येक वर्ग क्या करता है हमेशा उपयोगी होता है। दुर्भाग्य से, हर प्रोजेक्ट डेवलपर्स से बहुत दूर है। आप अक्सर ऐसा कुछ सुन सकते हैं: “ठीक है, यह पाथ क्लास के ऊपर एक ऐसा आवरण है, जिसे हम किसी तरह बनाते हैं और कभी-कभी पथ के बजाय उपयोग करते हैं। उसके पास एक ऐसा तरीका भी है जो सभी File.separator रास्तों को दोगुना कर सकता है - हमें क्लाउड को रिपोर्ट करते समय इस पद्धति की आवश्यकता होती है, और किसी कारण से यह पथ श्रेणी में समाप्त हो गया। "
• मानव मस्तिष्क एक साथ पांच से दस वस्तुओं के साथ काम करने में सक्षम है। अधिकांश लोगों के पास सात से अधिक नहीं है। तदनुसार, यदि किसी डेवलपर को किसी समस्या को हल करने के लिए सात से अधिक वस्तुओं के साथ काम करने की आवश्यकता होती है, तो वह या तो कुछ याद करेगा या एक तार्किक "छाता" के तहत कई वस्तुओं को पैक करने के लिए मजबूर किया जाएगा। और अगर आपको अभी भी इसे पैक करना है, तो इसे तुरंत, होशपूर्वक क्यों न करें, और इस छतरी को एक सार्थक नाम और एक स्पष्ट अनुबंध दें।

कैसे जांचें कि सब कुछ पर्याप्त रूप से दानेदार है? किसी सहकर्मी से आपको 5 (पांच) मिनट देने के लिए कहें। उस एप्लिकेशन का हिस्सा लें जिसे आप वर्तमान में बनाने पर काम कर रहे हैं। प्रत्येक वर्ग के लिए, एक सहयोगी को समझाएं कि यह कक्षा वास्तव में क्या करती है। यदि आप 5 मिनट में फिट नहीं होते हैं, या कोई सहकर्मी यह नहीं समझ सकता है कि इस या उस वर्ग की आवश्यकता क्यों है, तो शायद आपको कुछ बदलना चाहिए। ठीक है, या किसी अन्य सहयोगी के साथ फिर से प्रयोग को बदलने और संचालित करने के लिए नहीं।

वर्ग निर्भरता

मान लें कि हमें एक ज़िप संग्रह में पैक की गई पीडीएफ फाइल के लिए लिंक किए गए पाठ खंडों को 100 बाइट्स से अधिक समय तक चुनना है और उन्हें डेटाबेस में सहेजना है। इस तरह के मामलों में एक लोकप्रिय एंटीपैटर इस तरह दिखता है:

• एक वर्ग है जो ज़िप संग्रह खोलता है, इसमें एक पीडीएफ फाइल की तलाश करता है और इसे एक इनपुटस्ट्रीम के रूप में लौटाता है।
• इस वर्ग में एक वर्ग का लिंक है जो पाठ के पीडीएफ पैराग्राफ में खोज करता है।
• पीडीएफ के साथ काम करने वाले वर्ग, बदले में, उस वर्ग का लिंक होता है जो डेटाबेस में डेटा संग्रहीत करता है।

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

यह कैसे न करें:



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

यह कैसे करें:



यहाँ हमारे पास चार वर्ग हैं:

• एक वर्ग जो केवल एक ज़िप संग्रह के साथ काम करता है और पीडीएफ फाइलों की एक सूची देता है (एक तर्क कर सकता है - लौटने वाली फाइलें खराब हैं - वे बड़ी हैं और एप्लिकेशन को तोड़ देगी। लेकिन आइए इस मामले में "रिटर्न" शब्द को व्यापक अर्थों में पढ़ें। उदाहरण के लिए, यह इनपुटस्ट्रीम से स्ट्रीम करता है। )।
• पीडीएफ के साथ काम करने के लिए दूसरा वर्ग जिम्मेदार है।
• तीसरी श्रेणी डेटाबेस में पैराग्राफ को बचाने के अलावा कुछ भी नहीं जानती और नहीं कर सकती है।
• और चौथी श्रेणी, जिसमें कोड की कई पंक्तियाँ शामिल हैं, जिसमें सभी व्यावसायिक तर्क शामिल हैं जो एक स्क्रीन पर फिट होते हैं।

मैं एक बार फिर जोर देता हूं कि 2019 में जावा में कम से कम दो अच्छे (और कुछ हद तक कम) हैं
अच्छा) फ़ाइलों को स्थानांतरित करने के तरीके और स्मृति में ऑब्जेक्ट्स के रूप में सभी पैराग्राफ की पूरी सूची नहीं। यह है:

1. जावा स्ट्रीम एपीआई
2. कॉलबैक। यही है, एक व्यावसायिक फ़ंक्शन वाला वर्ग सीधे डेटा स्थानांतरित नहीं करता है, लेकिन ज़िप एक्सट्रैक्टर कहते हैं: यहां आपके लिए एक कॉलबैक है, एक पीडीएफ फाइल में पीडीएफ फाइलों को देखें, प्रत्येक फाइल के लिए एक इनपुटस्ट्रीम बनाएं और इसके साथ स्थानांतरित कॉलबैक को कॉल करें।

अभद्र व्यवहार

जब हम पूरी तरह से एक नई समस्या को हल करने की कोशिश नहीं कर रहे हैं जो पहले किसी के द्वारा हल नहीं की गई थी, लेकिन इसके विपरीत, कुछ ऐसा करना जो अन्य डेवलपर्स पहले से कई सौ (या सैकड़ों हजारों) पहले कर चुके हों, सभी टीम के सदस्यों को समाधान के चक्रवाती जटिलता और संसाधन खपत के बारे में कुछ उम्मीदें हैं । उदाहरण के लिए, यदि हमें एक फाइल को अक्षर z से शुरू करने वाले सभी शब्दों में ढूंढना है, तो यह डिस्क से ब्लॉक में फाइल का अनुक्रमिक, एक बार पढ़ने वाला है। यही है, अगर आप https://gist.github.com/jboner/2841832 पर ध्यान केंद्रित करते हैं - तो इस तरह के ऑपरेशन में प्रति 1 एमबी कई माइक्रोसेकंड लगेंगे, ठीक है, हो सकता है, प्रोग्रामिंग वातावरण और सिस्टम लोड के आधार पर, कई दसियों या सौ माइक्रोसेकंड, लेकिन एक सेकेंड भी नहीं। यह कई टन किलोबाइट मेमोरी ले जाएगा (हम इस सवाल को छोड़ देते हैं कि हम परिणामों के साथ क्या कर रहे हैं, यह एक अन्य वर्ग की चिंता है), और कोड सबसे अधिक संभावना एक स्क्रीन के बारे में ले जाएगा। साथ ही, हम उम्मीद करते हैं कि किसी अन्य सिस्टम संसाधनों का उपयोग नहीं किया जाएगा। यही है, कोड थ्रेड नहीं बनाएगा, डिस्क पर डेटा लिखेगा, नेटवर्क पर पैकेट भेजेगा और डेटाबेस में डेटा बचाएगा।

यह विधि कॉल की सामान्य अपेक्षा है:

zWordFinder.findZWords(inputStream). ... 

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

यदि आपके पास निहित व्यवहार का कोई उचित कारण नहीं है, तो कक्षा को फिर से लिखें।

विधि की जटिलता और संसाधन तीव्रता की अपेक्षाओं को कैसे समझा जाए? आपको इन सरल तरीकों में से एक का सहारा लेना होगा:

1. अनुभव के साथ, काफी व्यापक क्षितिज हासिल करें।
2. किसी सहकर्मी से पूछें - यह हमेशा किया जा सकता है।
3. विकास शुरू करने से पहले, कार्यान्वयन योजना के बारे में टीम के सदस्यों के साथ बात करें।
4. अपने आप से सवाल पूछने के लिए: "लेकिन क्या मैं इस पद्धति में बहुत अधिक अनावश्यक संसाधनों का उपयोग नहीं करता हूं?" यह आमतौर पर पर्याप्त है।

आपको ऑप्टिमाइज़ेशन में भी शामिल होने की ज़रूरत नहीं है - जब क्लास 100,000 द्वारा उपयोग किए जाने पर 100 बाइट की बचत होती है, तो अधिकांश अनुप्रयोगों के लिए बहुत मायने नहीं रखता है।

यह नियम ओवर-इंजीनियरिंग की समृद्ध दुनिया में एक खिड़की खोलता है, जैसे "आप एक महीने में 10 बाइट्स को सहेजने के लिए एक महीने क्यों नहीं बिताना चाहिए, जैसे सवालों के जवाब छिपाते हुए काम करने के लिए 10 जीबी की आवश्यकता होती है"। लेकिन मैं इस विषय को यहाँ विकसित नहीं करूँगा। वह एक अलग लेख की हकदार है।

अव्यय विधि नाम

जावा प्रोग्रामिंग में, वर्तमान में कक्षा के नाम और उनके व्यवहार के बारे में कई निहितार्थ हैं। उनमें से बहुत से नहीं हैं, लेकिन उन्हें तोड़ना बेहतर नहीं है। मैं उन चीजों को सूचीबद्ध करने की कोशिश करूंगा जो मेरे दिमाग में आती हैं:

• कंस्ट्रक्टर - वर्ग का एक उदाहरण बनाता है, कुछ काफी हद तक डेटा संरचनाओं को बना सकता है, लेकिन यह डेटाबेस के साथ काम नहीं करता है, डिस्क पर नहीं लिखता है, नेटवर्क पर डेटा नहीं भेजता है (मैं कहता हूं, अंतर्निहित लकड़हारा यह सब कर सकता है, लेकिन यह एक अलग कहानी है किसी भी स्थिति में, यह लॉगिंग विन्यासकर्ता के विवेक पर आधारित है)।
• Getter - getSomething () - ऑब्जेक्ट की गहराई से किसी प्रकार की मेमोरी संरचना लौटाता है। फिर से, यह डिस्क पर नहीं लिखता है, जटिल गणना नहीं करता है, नेटवर्क पर डेटा नहीं भेजता है, डेटाबेस के साथ काम नहीं करता है (जब यह एक आलसी ओआरएम क्षेत्र है, और यह केवल एक कारण है कि आलसी क्षेत्रों को बहुत सावधानी से इस्तेमाल किया जाना चाहिए) ।
• सेटर - setSomething (कुछ कुछ) - डेटा संरचना का मूल्य सेट करता है, जटिल गणना नहीं करता है, नेटवर्क पर डेटा नहीं भेजता है, डेटाबेस के साथ काम नहीं करता है। आमतौर पर, सेटर से किसी महत्वपूर्ण कंप्यूटिंग संसाधनों के व्यवहार या खपत का अनुमान लगाने की उम्मीद नहीं की जाती है।
• बराबर () और हैशकोड () - डेटा संरचना के आकार पर रैखिक रूप से निर्भर राशि में सरल गणना और तुलना के अलावा कुछ भी बिल्कुल भी अपेक्षित नहीं है। यही है, अगर हम तीन आदिम क्षेत्रों की वस्तु के लिए हैशकोड कहते हैं, तो यह उम्मीद है कि एन * 3 सरल कम्प्यूटेशनल निर्देशों को निष्पादित किया जाएगा।
• .Something () - यह एक ऐसी विधि होने की भी उम्मीद है जो एक डेटा प्रकार को दूसरे में परिवर्तित करती है, और रूपांतरण के लिए केवल संरचनाओं के आकार के लिए स्मृति की मात्रा की आवश्यकता होती है, और प्रोसेसर समय जो रैखिक रूप से संरचनाओं के आकार पर निर्भर करता है। यहां यह ध्यान दिया जाना चाहिए कि प्रकार रूपांतरण हमेशा रैखिक रूप से नहीं किया जा सकता है, उदाहरण के लिए, एक पिक्सेल छवि को एसवीजी प्रारूप में परिवर्तित करना एक बहुत ही गैर-तुच्छ कार्रवाई हो सकती है, लेकिन इस मामले में विधि को अलग तरीके से नाम देना बेहतर है। उदाहरण के लिए, computeAndConvertToSVG ​​() नाम कुछ अटपटा लगता है, लेकिन यह तुरंत बताता है कि कुछ महत्वपूर्ण गणना अंदर हो रही है।

मैं एक उदाहरण दूंगा। मैंने हाल ही में एक एप्लिकेशन ऑडिट किया था। काम के तर्क से, मुझे पता है कि कोड में कहीं भी आवेदन RabbitMQ कतार के सदस्य हैं। मैं कोड नीचे चला रहा हूँ - मुझे यह जगह नहीं मिल रही है मैं सीधे खरगोश के लिए एक अपील की तलाश में हूं, मैं ऊपर चढ़ना शुरू कर रहा हूं, मैं व्यापार प्रवाह में उस स्थान पर जा रहा हूं जहां सदस्यता वास्तव में होती है - मैं कसम खाना शुरू कर रहा हूं। यह कोड में कैसा दिखता है:

1. सेवा .getQueueListener (टिकरनाम) विधि को कहा जाता है - लौटे परिणाम की अनदेखी की जाती है। यह सचेत हो सकता है, लेकिन कोड का ऐसा टुकड़ा जहां विधि के परिणामों को नजरअंदाज किया जाता है, आवेदन में केवल एक ही नहीं है।
2. अंदर, टिकरनाम को शून्य के लिए जांचा जाता है और एक अन्य getQueueListenerByName (टिकरनाम) विधि कहा जाता है।
3. इसके अंदर, क्यूलेस्टीनर वर्ग का एक उदाहरण हैश से टिकर के नाम से लिया जाता है (यदि यह नहीं है, तो इसे बनाया गया है), और गेटबसक्रिप्शन () विधि को इस पर कहा जाता है।
4. और अब, getSubscription () विधि के अंदर, सदस्यता वास्तव में होती है। और यह कहीं एक विधि के बीच में होता है तीन स्क्रीन का आकार।

मैं आपको स्पष्ट रूप से बताऊंगा - पूरी श्रृंखला के माध्यम से चलने के बिना और कोड के एक चौकस दर्जन स्क्रीन को पढ़े बिना, यह अनुमान लगाना अवास्तविक था कि सदस्यता कहाँ है। अगर विधि को subscribeToQueueByTicker (tickerName) कहा जाता है, तो यह मुझे बहुत समय बचाएगा।

उपयोगिता वर्ग

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

यह कैसे तय करें कि आपको एक अमूर्त वर्ग के कारखाने (या किसी अन्य पैटर्न को इंटरफ़ेस से अधिक जटिल) की आवश्यकता है या नहीं? कुछ सरल विचार हैं:

1. यदि आप स्प्रिंग में एप्लिकेशन लिख रहे हैं, तो 99% समय की आवश्यकता नहीं है। स्प्रिंग आपको उच्च स्तर के बिल्डिंग ब्लॉक्स प्रदान करता है, उनका उपयोग करें। अधिकतम जो आपको उपयोगी लग सकता है वह एक अमूर्त वर्ग है।
2. यदि बिंदु 1 ने अभी भी आपको स्पष्ट उत्तर नहीं दिया है - याद रखें कि प्रत्येक टेम्पलेट एप्लिकेशन की जटिलता के लिए +1000 अंक है। ध्यान से विश्लेषण करें कि क्या टेम्पलेट का उपयोग करने के लाभ इससे नुकसान पहुंचाते हैं। एक रूपक की ओर मुड़ते हुए, याद रखें कि प्रत्येक दवा न केवल चंगा करती है, बल्कि थोड़ा नुकसान भी पहुंचाती है। एक ही बार में सारी गोलियां न पिएं।

आपको इसकी आवश्यकता कैसे है, इसका एक अच्छा उदाहरण आप यहां देख सकते हैं।

निष्कर्ष

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