कई परियोजनाओं में एक विकास परियोजना (जैसे एएसपी.नेट एमवीसी अनुप्रयोग) को विभाजित करने के आम कारण क्या हैं? कोड संगठन फ़ोल्डरों के माध्यम से भी किया जा सकता है। कई परियोजनाएं गोलाकार संदर्भ संघर्ष उत्पन्न करती हैं और उनको प्रबंधित/हल करने के द्वारा जटिलता में वृद्धि करती हैं।परियोजना को कई परियोजनाओं में विभाजित करने के कारण?
तो, क्यों?
एक संभावना है कि एक प्रणाली है कि एक दिया समूह (या एकल डेवलपर) शेष कोड के स्वतंत्र रूप से काम कर सकता है। दूसरा एक सामान्य उपयोगिता कोड को कारक बनाना है जिसे बाकी सिस्टम की जरूरत है - त्रुटि प्रबंधन, लॉगिंग और सामान्य उपयोगिता जैसी चीजें ध्यान में आती हैं।
बेशक, जब किसी विशेष कार्य/वर्ग/फ़ाइल में क्या होता है, इस बारे में सोचते समय, जहां सीमाएं कला का विषय है, विज्ञान नहीं।
एक चीज़ के लिए स्वामित्व। यदि आपके पास कोड बेस के विभिन्न हिस्सों के लिए ज़िम्मेदार डेवलपर्स हैं तो परियोजना को विभाजित करने के लिए प्राकृतिक चीज है। एक परियोजनाओं को कार्यक्षमता से विभाजित भी करेगा। इससे संघर्ष और जटिलता कम हो जाती है। यदि यह बढ़ता है, तो इसका मतलब सिर्फ संचार की कमी है और आप इसे गलत कर रहे हैं।
एक उदाहरण मैं सोच सकता हूं कि आपको एक ऐसी परियोजना विकसित करने में मिल सकता है जो आप एक पुस्तकालय विकसित करना समाप्त कर सकते हैं जो अधिक सामान्य उपयोग हो सकता है और जो अपनी परियोजना होने का हकदार है। उदाहरण के लिए शायद आप एक वीडियो गेम पर काम कर रहे हैं, और आप एक ऑडियो लाइब्रेरी लिखना समाप्त कर देते हैं जो विशेष रूप से गेम प्रोजेक्ट से बंधे नहीं है।
कुछ कारणों
Encapsulation कर रहे हैं - एक और पुस्तकालय में दिनचर्या का एक सेट पैकेजिंग करके, या तो एक स्थिर पुस्तकालय या DLLs का एक सेट के रूप में, यह एक ब्लैक बॉक्स हो जाता है। यह एक अच्छा काला बॉक्स होने के लिए, आपको यह सुनिश्चित करना है कि आप सही इनपुट दें और सही आउटपुट प्राप्त करें। जब आप उस लाइब्रेरी का पुन: उपयोग करते हैं तो यह मदद करता है। यह कुछ नियमों को भी लागू करता है और हैक्स द्वारा प्रोग्रामिंग को रोकता है ('हम्म ... मैं अभी उस सदस्य को अभी सार्वजनिक कर दूंगा')
संकलन समय कम करता है - लाइब्रेरी पहले ही अनुपालन की जाती है; आपको इसे संकलित समय पर पुनर्निर्माण करने की आवश्यकता नहीं है, बस उससे लिंक करें (मान लें कि आप सी ++ कर रहे हैं)।
Decoupling - एक स्टैंडअलोन पुस्तकालयों में अपनी कक्षाओं को घेरकर, आप युग्मन को कम कर सकते हैं और आपको अन्य उद्देश्य के लिए लाइब्रेरी का पुन: उपयोग करने की अनुमति देता है। इसी प्रकार, जब तक लाइब्रेरी का इंटरफ़ेस परिवर्तित नहीं होता है, तब तक आप अपनी पसंद की लाइब्रेरी में परिवर्तन कर सकते हैं, और जो लोग इसे लिंक करते हैं या इसका संदर्भ देते हैं उन्हें अपने कोड को बिल्कुल बदलने की आवश्यकता नहीं होती है। डीएलएल इस पहलू में उपयोगी हैं कि पुन: संकलन की आवश्यकता नहीं है, लेकिन यदि कई अनुप्रयोग एक ही डीएलएल के विभिन्न संस्करण स्थापित करते हैं तो काम करने में मुश्किल हो सकती है। आप क्लाइंट के कोड को प्रभावित किए बिना पुस्तकालयों को अपडेट कर सकते हैं। जबकि आप केवल फ़ोल्डरों के साथ ऐसा ही कर सकते हैं, इस व्यवहार को बल देने के लिए कोई स्पष्ट तंत्र नहीं है।
इसके अलावा, विभिन्न पुस्तकालयों के इस अनुशासन का अभ्यास करके, आप यह भी सुनिश्चित कर सकते हैं कि आपने जो लिखा है वह सामान्य और कार्यान्वयन से decoupled है।
लाइसेंसिंग/व्यावसायीकरण - ठीक है, मुझे लगता है कि यह काफी स्पष्ट है।
कोड पुन: उपयोग। आइए मान लें कि आपके पास प्रोजेक्ट ए है और आप एक नया प्रोजेक्ट बी शुरू करते हैं जिसमें प्रोजेक्ट ए के समान कार्य हैं। ए के साझा हिस्सों को खींचने और उन्हें लाइब्रेरी में बनाने का अर्थ है जिसका उपयोग ए और बी दोनों द्वारा किया जा सकता है। यह आपको दो स्थानों में एक ही कोड को बनाए रखने के बिना दोनों में कोड रखने की अनुमति देता है।
कोड पुन: उपयोग, उलटा हुआ। मान लें कि आपके पास एक परियोजना है जो एक मंच पर काम करती है। अब आप इसे दो प्लेटफार्मों पर काम करना चाहते हैं। यदि आप प्लेटफ़ॉर्म-निर्भर कोड को अलग कर सकते हैं, तो आप प्रत्येक प्लेटफ़ॉर्म-निर्भर लाइब्रेरी के लिए अलग-अलग प्रोजेक्ट शुरू कर सकते हैं और फिर विभिन्न प्लेटफ़ॉर्म के लिए अलग-अलग पुस्तकालयों के साथ अपने केंद्रीय कोडबेस को संकलित कर सकते हैं।
डाउनवॉट्स क्यों? – Imagist
एकाधिक असेंबली में कोड के मूल्य पर सवाल पूछने के बजाय, अपने सभी कोड को एक ही स्थान पर क्लैंप करने के मूल्य पर सवाल उठाएं।
क्या आप अपने रसोईघर में सब कुछ एक कैबिनेट में डाल देंगे?
परिपत्र संदर्भ परिपत्र संदर्भ हैं, चाहे वे असेंबली के बीच हों या उनके भीतर हों। अपमानजनक घटकों का डिजाइन सबसे अधिक संभावना उप-इष्टतम है; विधानसभाओं के माध्यम से eschewing संगठन विडंबनात्मक रूप से संकलक को आपके लिए स्थिति का पता लगाने से रोकता है।
मैं बयान है कि आप परियोजनाओं के साथ के रूप में कोड बस के रूप में अच्छी तरह से साथ फ़ोल्डरों को व्यवस्थित कर सकते हैं समझ में नहीं आता। यदि यह सच था, तो हमारे ऑपरेटिंग सिस्टम में अलग-अलग ड्राइव की अवधारणा नहीं होगी; वे सिर्फ एक विशाल फ़ोल्डर संरचना होगी। उच्च-आदेश संगठनात्मक पैटर्न सरल फ़ोल्डरों की तुलना में एक अलग तरह का इरादा व्यक्त करते हैं।
परियोजनाओं कहते हैं कि "इन अवधारणाओं को बारीकी से संबंधित हैं, और केवल सतही तौर पर अन्य अवधारणाओं से संबंधित।"
आप सही हैं; मुझे बस बहुत सारे परिपत्र संदर्भों का सामना करना पड़ रहा है (इस प्रश्न में वर्णित है: http://stackoverflow.com/questions/1320561/resolving-circular-references-c) जो प्रोजेक्ट को अलग करना बेहद कठिन बनाते हैं, या मैं कुछ कर रहा हूं विशाल डिजाइन गलतियों जो मुझे पता नहीं है (और से सीखना चाहते हैं)। – Alex
लिंक किए गए प्रश्न का उत्तर जोड़ा गया। –
यहां कुछ अच्छे उत्तर दिए गए हैं, इसलिए मैं दोहराने की कोशिश नहीं करूंगा। अपने आप परियोजना के लिए बाहर बंटवारे कोड की
एक लाभ यह कई आवेदन भर में विधानसभा का पुन: उपयोग किया जा सके।
मैं कार्यात्मक दृष्टिकोण के रूप में अच्छी तरह से उल्लेख किया है (जैसे सूची, शिपिंग, आदि सभी अपनी परियोजनाओं मिल सकता है) पसंद आया। एक और विचार तैनाती मॉडल पर विचार करना है। परतों, स्तरों या सर्वरों के बीच साझा कोड शायद इसकी अपनी आम परियोजना में होना चाहिए (या यदि बेहतर नियंत्रण वांछित है तो परियोजनाओं का सेट होना चाहिए)। एक निश्चित स्तर के लिए निर्धारित कोड अपने स्वयं के प्रोजेक्ट में हो सकता है। जैसे यदि आपके पास एक अलग वेब सर्वर और एप्लिकेशन सर्वर था तो आप एप्लिकेशन सर्वर पर यूआई कोड को तैनात नहीं करना चाहते हैं।
विभाजित करने के लिए छोटे वृद्धिशील तैनात एक बार आवेदन उत्पादन में है अनुमति देने के लिए हो सकता है एक और कारण। मान लें कि आपको एक आपातकालीन उत्पादन बग मिलती है जिसे ठीक करने की आवश्यकता है। यदि छोटे बदलाव के लिए पूरे (एक परियोजना) अनुप्रयोग के पुनर्निर्माण की आवश्यकता होती है तो आपको क्यूए में एक छोटे से परीक्षण चक्र को उचित ठहराने में कठिनाई हो सकती है। यदि आप कार्यक्षमता के एक छोटे सेट के साथ केवल एक असेंबली तैनात कर रहे थे तो आपके पास एक आसान बिक्री हो सकती है।
यह कोड स्वामित्व को और अधिक विशिष्ट बनाता है, जो मुझे लगता है कि एक बुरी चीज है। विशेष कोड स्वामित्व के लिए अधिक संचार की आवश्यकता होती है (जैसा आपने नोट किया) और संचार हमेशा प्राप्त करना मुश्किल होता है। इसके लिए अधिक सहयोग की भी आवश्यकता है (यदि मुझे आपके कोड को बदलने की ज़रूरत है, तो अब इसे स्वयं करना बहुत कठिन है) जो भी प्राप्त करना मुश्किल है। इस परिदृश्य में, एक बुरी टीम खिलाड़ी सभी के लिए f *** चीजें कर सकता है। – Imagist