लाइब्रेरी डिज़ाइन के संदर्भ में "कोर" का क्या अर्थ है?

Question

मैं अक्सर "कोर" के साथ पुस्तकालय नामकरण अन्य डेवलपर्स को देखता हूं। इसका वास्तव में क्या अर्थ है?

Answer 1

मेरी राय में, कोर का अर्थ कुछ अनिवार्य है। उपयोगिता उद्देश्यों के साथ गणित कार्य और अन्य कार्य कोर में नहीं हैं। वे बल्कि "उपयोग" हैं।

मूल वह हिस्सा है जो सब कुछ मौजूद है - इसके बिना, दूसरों को कोई समझ नहीं आता है। अन्य सामान, जो कोर में नहीं है (डिज़ाइन द्वारा हमेशा संभव नहीं) हटाया जा सकता है।

Answer 2

मैं उस सम्मेलन का उपयोग करता हूं और यह मूल रूप से सामान्य उपयोगिता कक्षाओं और कोड के साथ एक कोर क्लास लाइब्रेरी है जिसका वास्तव में अपनी पुस्तकालय में कोई स्थान नहीं है।

उदाहरण के लिए, कई वर्गों, अतिरिक्त गणित कार्यों आदि के लिए विस्तार विधियां, जो चीजें उनके लिए एक अन्य परियोजना को वारंट करने के लिए पर्याप्त नहीं हैं।

हालांकि मुझे अन्य लोगों को क्या पता नहीं है।

Answer 3

I asked Bing "कोर" को परिभाषित करने के लिए। परिभाषाओं यह के साथ आया था:

अनिवार्य हिस्सा: केंद्रीय या कुछ और का सबसे महत्वपूर्ण हिस्सा

तो बुनियादी तौर पर, जब कोई नाम एक पुस्तकालय कोर, यह केंद्रीय और सबसे है उनके आवेदन और/या ढांचे का महत्वपूर्ण हिस्सा :-)

Answer 4

मैं कोर को एप्लिकेशन के सार दिल के रूप में देखता हूं। कोर आमतौर पर पूरे एप्लिकेशन के व्यवहार को परिभाषित करने के लिए पर्याप्त तर्क लागू करता है।

तो मेरे विचार में डेटा पहुंच और प्रस्तुति कोर का हिस्सा नहीं होना चाहिए। यह वेब और डेस्कटॉप अनुप्रयोगों को एक ही कोर मॉड्यूल साझा करने की अनुमति देता है।

आपके मामले में मुझे कोर मॉड्यूल में व्यावसायिक तर्क, त्रुटि प्रबंधन और कॉन्फ़िगरेशन शामिल होगा।

मैं यह भी मानता हूं कि एक बड़ा कोर मॉड्यूल रखने का मुख्य कारण बहुत से छोटे मॉड्यूल बनाए रखने की लागत से बचने के लिए है।

Answer 5

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

Answer 6

इसे शायद पाखंडी के रूप में माना जाएगा, लेकिन डेटा एक्सेस, व्यवसाय तर्क आदि के लिए अलग-अलग परियोजनाओं के साथ कई वर्षों के संरचना समाधानों के बाद, मैं उन परतों को MyApp नामक एक परियोजना में रखने की अधिक संभावना रखता हूं। कि एक बुनियादी समाधान में केवल मूल परियोजना और यूआई परियोजना शामिल होगी। ऐसा नहीं है कि किसी अन्य परियोजना की कभी आवश्यकता नहीं होगी या जोड़ा जाएगा (उदा। MyApp.Tests), लेकिन मूल संरचना उन दोनों पर आधारित होगी।

संपादित करें: टिप्पणियों में प्रति सुझाव संक्षिप्त।

Answer 7

पहले से पोस्ट किए गए उत्तरों के आधार पर, स्पष्ट रूप से "कोर" को परिभाषित करने का कोई "मानक" तरीका नहीं है क्योंकि यह विकासशील पुस्तकालयों से संबंधित है।

तो मैं "सही" होने की चिंता नहीं करता। जैसा कि आप फिट देखते हैं शब्द का प्रयोग करें।