मेरे पास कुछ जावा प्रोग्राम हैं, अब मैं यह जानना चाहता हूं कि यह मॉड्यूलर है या नहीं, यदि यह मॉड्यूलर है तो कितनी हद तक, क्योंकि मॉड्यूलरिटी कभी द्विआधारी अवधि यानी 0 या 1. कभी भी तय नहीं कर सकती कोड इस हद तक मॉड्यूलर है। मैं जानना चाहता हूं कि कोड को और अधिक मॉड्यूलर कैसे बनाया जाए?कोड मॉड्यूलर कैसे बनाएं?
मान लीजिए कि मैं आपका प्रश्न समझता हूं, कि आप जानना चाहते हैं कि यह कोड मॉड्यूलर बनाता है, क्योंकि कोड मॉड्यूल को एक दूसरे के बीच काम करने के लिए कुछ निर्भरता की आवश्यकता होगी। यह मेरा जवाब है:
यदि आप अपने सिस्टम को मॉड्यूल में तोड़ सकते हैं, और आप अलगाव में उन मॉड्यूल का परीक्षण कर सकते हैं, यह एक अच्छा संकेत है कि एक प्रणाली मॉड्यूलर है।
जैसा कि आप कहते हैं कि मॉड्यूलरिटी बाइनरी चीज नहीं है, इसलिए यह आपकी सापेक्ष परिभाषा पर निर्भर करती है।
मैं कहूंगा: क्या आप किसी भी प्रोग्राम में किसी दिए गए विधि का उपयोग कर सकते हैं जहां आपको उस कार्य को करने की आवश्यकता है? क्या यह "ब्लैक बॉक्स" है जहां आपको यह जानने की आवश्यकता नहीं होगी कि यह हुड के नीचे क्या कर रहा था? अगर उत्तर नहीं है, यानी विधि केवल उस कार्यक्रम में ठीक से काम करेगी तो यह वास्तव में मॉड्यूलर नहीं है।
मॉड्यूलरिटी इस बात से संबंधित है कि कोड कभी भी विकसित कर रहा है। लेकिन मुझे लगता है कि आम सहमति यह है कि मॉड्यूलर कोड कोड है जिसमें भाग होते हैं जिन्हें अधिकांश मूल कोड को बदले बिना आसानी से बदला जा सकता है।
आईएमएचओ, यदि आपके पास 3 मॉड्यूल ए बी और सी हैं और आप मॉड्यूल सी को पूरी तरह से बदलना या बदलना चाहते हैं, तो ऐसा करने के लिए यह एक आसान काम है, तो आपके पास मॉड्यूलर कोड है।
आप प्रकार और पैकेज के बीच निर्भरताओं का विश्लेषण करने के लिए CAP जैसे कोड विश्लेषण टूल का उपयोग कर सकते हैं। वे किसी भी चक्रीय निर्भरता को खोजने और हटाने में आपकी सहायता करेंगे, जो मॉड्यूलर कोड विकसित करने की कोशिश करते समय अक्सर समस्या होती है। यदि कोई चक्रीय निर्भरता नहीं है, तो आप अपने कोड को पृथक जार में अलग करना शुरू कर सकते हैं।
सामान्य रूप से इंटरफ़ेस को कोड करने के लिए यह अच्छा अभ्यास है यदि आप कर सकते हैं, तो आम तौर पर इसका मतलब है कि आपके कोड को आसानी से दोबारा संदर्भित किया जा सकता है और/या विभिन्न संदर्भों में उपयोग किया जा सकता है।
निर्भरता इंजेक्शन ढांचे जैसे Spring आपके डिजाइन की मॉड्यूलरिटी के साथ भी मदद कर सकते हैं। जैसे कि कुछ बाह्य विन्यास प्रक्रियाओं द्वारा प्रकारों को उनकी निर्भरताओं से इंजेक्शन दिया जाता है, उन्हें कार्यान्वयन पर प्रत्यक्ष निर्भरता की आवश्यकता नहीं होती है।
कुछ मानक प्रतिरूपकता के लिए:
और अपने कोड अधिक मॉड्यूलर पहले आप, अपने आप को ऊपर सवाल पूछने उनके लिए विशिष्ट जवाब प्राप्त और फिर एक नजर है चाहिए बनाने पर software quality
आपकी चिंता का सवाल है पर यह एक this
पर बुनियादी दर्शन आसानी से समझ और सुलभ निर्देशिका लेआउट की एक भीड़ भर में बड़े करीने से व्यवस्था की संभव के रूप में छोटे एक कोड टुकड़ों में आपके आवेदन को तोड़ने के लिए है।
आपके आवेदन में प्रत्येक विधि को आवश्यक न्यूनतम प्रसंस्करण की आवश्यकता नहीं है। अधिक से अधिक बड़े स्तर तरीकों में इन विधियों के संयोजन आप अपने आवेदन वापस करने के लिए नेतृत्व चाहिए
एक और बेंचमार्क "हटाना मानदंड" हो सकता है: यदि आप अपने प्रोग्राम से एक्स (पैकेज, कक्षा, विधि, फ़ील्ड) हटाते हैं, तो क्या टूटता है? यदि ब्रेक हैं, तो हटाए गए आइटम से वे "दूर" कैसे हैं? यदि टूटे हुए सामान दूर हैं, तो इसका मतलब है कि एक्स कम मॉड्यूलर था। –
(पिछली टिप्पणी में जोड़ें) - जब आप कुछ हटाते हैं, तो आप तुरंत शेष कार्यक्रम के साथ अपने कनेक्शन का पर्दाफाश करते हैं - उन सभी स्थानों पर जहां कोड कोड करने के लिए वायर्ड किया जाता है। अधिक मॉड्यूलरिटी * आमतौर पर * कम कनेक्शन बिंदु का मतलब है, और आमतौर पर इसका मतलब है कि कनेक्शन बिंदु अधिक "स्थानीय" दायरे में हैं (उदाहरण के लिए, एक ही पैकेज में)। –
+1! बिलकुल सही! – OrangeRind
प्रमुख बिंदु हैं
ऐसे मॉड्यूल सिस्टम का एक अच्छा उदाहरण डिस्क ब्रेक और कार स्टीरियो जैसे मानक कार भागों है। जब आप कारें बना रहे हों तो आप स्क्रैच से कार स्टीरियो बनाना नहीं चाहते हैं। आप इसे खरीद लेंगे और इसे प्लग करेंगे। आप यह भी नहीं चाहते कि ब्रैकिंग सिस्टम कार स्टीरियो को प्रभावित करे - या ब्रेक सिस्टम को प्रभावित करने वाली खराब कार स्टीरियो।
अपने प्रश्न का उत्तर देने के लिए, "मैं कैसे तय करूं कि विशेष कोड मॉड्यूलर तक बहुत अधिक है," हम मॉड्यूलरिटी का परीक्षण करने के लिए प्रश्न बना सकते हैं। क्या आप आसानी से अपने आवेदन के अन्य हिस्सों को प्रभावित किए बिना किसी अन्य चीज़ के साथ अपने मॉड्यूल को प्रतिस्थापित कर सकते हैं?
एक्सएमएल पार्सर्स एक और उदाहरण हो सकता है। एक बार जब आप डीओएम इंटरफेस प्राप्त कर लेते हैं, तो आप वास्तव में परवाह नहीं करते कि एक्सएमएल पार्सर का कौन सा कार्यान्वयन नीचे उपयोग किया जाता है (उदा। अपाचे जेरिस या जेएक्सपी)।
जावा में, एक और प्रश्न हो सकता है: क्या सभी कार्यक्षमता interface एस के माध्यम से सुलभ हैं? इंटरफ़ेस बहुत कम युग्मन की देखभाल करता है।
इसके अलावा, क्या आप एक वाक्य के साथ अपने सिस्टम में प्रत्येक मॉड्यूल का वर्णन कर सकते हैं? उदाहरण के लिए, एक कार स्टीरियो संगीत और रेडियो बजाता है। डिस्क ब्रेक वाहन को सुरक्षित रूप से कम कर देता है।
विकिपीडिया के अनुसार (यहाँ मैं क्या What is component driven development? को पत्र लिखा है), घटक आधारित विकास Component-based software engineering (CBSE) के लिए एक उपनाम है।
[यह] सॉफ्टवेयर इंजीनियरिंग की एक शाखा है, प्राथमिकता जिनमें से व्यापक कार्यक्षमता उपलब्ध के संबंध में चिंताओं की जुदाई किसी दिए गए सॉफ्टवेयर प्रणाली भर में है।
यह कुछ अस्पष्ट है, तो चलिए अधिक जानकारी देखें।
एक व्यक्ति घटक एक सॉफ्टवेयर पैकेज, या एक मॉड्यूल है, कि संबंधित कार्य (या डेटा) का एक सेट समाहित।
सभी सिस्टम प्रक्रियाओं अलग घटकों में रखा जाता है ताकि प्रत्येक घटक अंदर डेटा और कार्यों के सभी अर्थ की दृष्टि से संबंधित (बस वर्गों की सामग्री के साथ के रूप में) हैं। इस सिद्धांत के कारण, अक्सर यह कहा जाता है कि घटक मॉड्यूलर और समेकित हैं।
तो, इस परिभाषा के अनुसार, एक घटक तब तक कुछ भी हो सकता है जब तक यह एक चीज वास्तव में अच्छी तरह से और केवल एक चीज हो।
के साथ पूरे सिस्टम में समन्वय के संबंध में, घटकों इंटरफेस के माध्यम से एक दूसरे के साथ संवाद । [...] इस सिद्धांत के परिणाम encapsulated के रूप में संदर्भित घटकों में परिणाम।
तो यह अच्छा लगता है कि हम अच्छे एपीआई या एसओए के बारे में क्या सोचते हैं, उतना ही अधिक लग रहा है।
प्रदान की इंटरफेस एक लॉलीपॉप का प्रतिनिधित्व कर रहे हैं और आवश्यक इंटरफेस यूएमएल में घटक के बाहरी छोर से जुड़ी एक खुले सॉकेट प्रतीक द्वारा प्रतिनिधित्व कर रहे हैं।
घटकों का एक अन्य महत्वपूर्ण विशेषता यह है कि वे substitutable कर रहे हैं, ताकि एक घटक ( डिजाइन समय में या रन-टाइम) किसी अन्य के द्वारा प्रतिस्थापित किया जा सकता है, अगर है प्रारंभिक घटक (इंटरफेस के माध्यम से व्यक्त) की आवश्यकताओं उत्तराधिकारी घटक द्वारा से मुलाकात की जाती है।
पुन: प्रयोज्यता एक महत्वपूर्ण एक उच्च गुणवत्ता सॉफ़्टवेयर घटक की विशेषता है। एक सॉफ्टवेयर घटक डिज़ाइन किया जाना चाहिए और लागू किया जाना चाहिए ताकि इसे कई अलग-अलग कार्यक्रमों में का पुन: उपयोग किया जा सके।
सबस्टिट्यूटिबिलिटी और पुन: प्रयोज्यता घटक को एक घटक बनाती है। तो इस और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के बीच क्या अंतर है?
वस्तु उन्मुख प्रोग्रामिंग (OOP) में यह विचार है कि सॉफ्टवेयर वास्तविक या काल्पनिक वस्तुओं यह प्रतिनिधित्व के मानसिक मॉडल के अनुसार लिखा जाना चाहिए है। [...]
घटक आधारित सॉफ्टवेयर इंजीनियरिंग, इसके विपरीत, ऐसी कोई धारणाएं बनाता है, और बदले में कहा गया इलेक्ट्रॉनिक्स या के क्षेत्र में की तरह एक साथ पूर्वनिर्मित घटकों चिपकाने ज्यादा द्वारा कि सॉफ्टवेयर विकसित किया जाना चाहिए यांत्रिकी।
कैसे कोड अधिक मॉड्यूलर बनाने के लिए के अपने विशिष्ट सवाल का जवाब करने के लिए, दृष्टिकोण के एक जोड़े हैं:
सबसे अच्छा उपकरण में से एक मॉड्यूलर के लिए कोड फिर से उपयोग खोलना है। यदि आपको लगता है कि आपका कोड एक ही स्थान पर एक ही सटीक (या बहुत समान) चीज करता है, तो यह मॉड्यूलरिंग के लिए एक अच्छा उम्मीदवार है।
यह निर्धारित करें कि तर्क के कौन से टुकड़े स्वतंत्र किए जा सकते हैं, इस अर्थ में कि अन्य तर्क उन्हें बिना किसी निर्माण के जानने के लिए उपयोग करेंगे। यह कुछ हद तक समान है जो आप ओओ डिजाइन में करते हैं, हालांकि मॉड्यूल/घटक को ओओ में मॉडलिंग ऑब्जेक्ट के अनुरूप होने की आवश्यकता नहीं है।
package-by-feature विचार कोड को अधिक मॉड्यूलर बनाने में मदद करता है।
कई उदाहरण पहले परतों में वेब डिवाइड आवेदनों पर देखा, नहीं
यह बेहतर लगता है, तथापि, विभाजित करने के लिए आवेदन पत्र की सुविधा शीर्ष स्तर के पैकेज का उपयोग करके सुविधाओं के साथ संरेखित करें, परत नहीं।
यहां एक वेब ऐप का example है जो पैकेज-बाय-फीचर का उपयोग करता है। शीर्ष-स्तरीय पैकेज के नामों पर ध्यान दें, जो एप्लिकेशन में वास्तविक सुविधाओं की सूची के रूप में पढ़ते हैं। ध्यान दें कि प्रत्येक पैकेज में किसी सुविधा से संबंधित सभी आइटम कैसे होते हैं - आइटम सभी जगहों पर फैले नहीं होते हैं; अधिकांश समय, वे सभी एक ही पैकेज/निर्देशिका में हैं।
आमतौर पर, इस तरह के ऐप में एक सुविधा को हटाने के लिए एक ही ऑपरेशन में कार्यान्वित किया जा सकता है - एक निर्देशिका का विलोपन।
चूंकि इसे 'ओजीआई' के साथ टैग किया गया है, इसलिए मैं ओएसजीआई से संबंधित परिप्रेक्ष्य में फेंक सकता हूं।
संक्षिप्त उत्तर यह है कि छोटे चरणों में मॉड्यूलर के लिए पूरी तरह से स्पेगेटी कोड से जाना संभव है; यह एक बड़ा धमाका नहीं होना चाहिए। उदाहरण के लिए, यहां तक कि स्पेगेटी कोड कुछ प्रकार की बोलोग्नाइज लॉगिंग लाइब्रेरी पर निर्भर करता है, इसलिए कुछ अर्थों में, यह पहले से ही मॉड्यूलर है, बस इसमें एक बहुत बड़ी मेटबॉल (माफ करना, मॉड्यूल) के साथ।
यह चाल बड़ी मांसपेशियों को एक छोटे हिस्से में तोड़ने और फिर थोड़ा कम मांसपेशियों को तोड़ने और फिर रिकर्स करना है। यह सब एक ही में जाने के लिए नहीं है; बस हर बार थोड़ी देर चिपकाएं जब तक कि हटाने के लिए कुछ भी नहीं बचा है।
ओएसजीआई के लिए, अभी भी एक बंडल में उबेर-जार डालना संभव है। वास्तव में, आप बिट्स को बदले बिना ऐसा कर सकते हैं; या तो Manifest.MF को जगह में संशोधित करके, या किसी अन्य JAR में लपेटकर और बंडल-क्लासपाथ निर्दिष्ट करें: मेनिबेल.जेर मेनिफेस्ट में।
यह विफल होने पर, बीएनडी जैसे टूल आपको आवश्यक डेटा उत्पन्न करने में मदद कर सकते हैं, और फिर इसे आसानी से ओएसजीआई रनटाइम में छोड़ दिया जा सकता है। लेकिन अधिकतर युग्मित कोड से सावधान रहें, और सामान जो क्लासलोडर्स के साथ घूमते हैं - वे आपको यात्रा करेंगे।
Hej,
देखें, "सॉफ्टवेयर संपुटित कैसे (भाग 1)," यहाँ:
http://www.edmundkirwan.com/encap/overview/paper7.html
सादर,
एड।
यदि कोड वास्तव में मॉड्यूलर है, तो प्रत्येक घटक एक ब्लैक बॉक्स होना चाहिए। कम ज्ञान घटक एक-दूसरे के बारे में जानते हैं, सिस्टम को अधिक मॉड्यूलर। – Kevin