ढांचे के निर्माण के दौरान विचार किया जाना चाहिए

Question

हम एक ढांचा बनाने की योजना बना रहे हैं: लागत-आकलन ढांचा जिसका उपयोग हमारे संगठन के डोमेन में किया जाएगा।

उच्च स्तरीय आवश्यकता इस तरह कुछ है: यदि मैं एक निश्चित उत्पाद विकसित करता हूं, तो मुझे कितना खर्च आएगा? इस जेनरेट की गई लागत का इस्तेमाल विक्रेताओं द्वारा उद्धृत लागत के साथ तुलना करने के लिए किया जाएगा और निर्णय लेने के लिए विक्रेता के चयन के लिए आना होगा।

अब, मेरा प्रश्न है: ढांचे के विकास के दौरान क्या विचार करना चाहिए?

मेरे विचारों की

कुछ:

1. लागू उच्च स्तरीय और सार कक्षाओं के माध्यम से आवश्यकताओं इंटरफेस
2. उपयोगिता वर्गों कि फ्रेमवर्क उपयोगकर्ताओं के लिए उपयोगी हो सकता है प्रदान करें।
3. विचार करें कि आंतरिक-प्रकार का मेटाडाटा क्या होना चाहिए - जो फ्रेमवर्क उपयोगकर्ताओं को नहीं दिखाया जाना चाहिए।
4. डिज़ाइन पैटर टेम्पलेट की तरह उपयोग करने के लिए।
5. इनपुट कक्षाओं के गुण और विधियां।

Answer 1

कुछ विचार:

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

Answer 2

यहाँ मैं कैसे आगे बढ़ना चाहते हैं:

1. एक व्यापक उच्च स्तरीय डिजाइन करते हैं - चीजों की तरह यह एक वेब अनुप्रयोग या मोटी ग्राहक है, वहाँ एक मध्य स्तरीय, कैसे होगा डीबी बातचीत है ऐसा होता है, क्या एपीआई/प्रौद्योगिकियों का उपयोग किया जाएगा, आदि
2. एक ऐसी सुविधा चुनें जो आपको कोड करने की अनुमति देगी हालांकि आवेदन के सभी स्तर (जिसे आमतौर पर स्पाइक के रूप में जाना जाता है)।
3. उस सुविधा को काम करने के लिए परीक्षण के साथ-साथ उस सुविधा को बनाने के लिए न्यूनतम न्यूनतम कार्यान्वित करें (Keep It Simple, Stupid) परीक्षणों के साथ यह काम करता है।
4. एक और सुविधा गेटो 3 चुनें (आवश्यकतानुसार refactoring)।

मुझे हमेशा यह पता चला है कि काम करने का यह तरीका सिस्टम विकसित करता है और वास्तव में कुछ काम करना आवश्यक है (पेपर डिज़ाइन के साथ होने वाली कल्पना की उड़ानों की बजाय) पर आपके डिजाइन को केंद्रित करता है।

और वहाँ मुझे सोच मुझ में agilist सामान्य प्रोग्रामिंग सलाह से ;-)

Answer 3

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

http://en.wikipedia.org/wiki/Software_framework

इसके अलावा यहां एक अच्छा सारांश:

हमेशा की तरह विकिपीडिया एक अच्छा प्रारंभिक बिंदु है

http://www.acm.org/crossroads/xrds7-4/frameworks.html

आप गहराई में जाने में प्रशंसा पत्र पर एक नजर है चाहते हैं इन दोनों लेखों।

Answer 4

एपीआई अनुबंधों में इंटरफेस का उपयोग करें। यह आपको गन्दा विवरण पूरी तरह से decoupled रखने और जरूरत पड़ने पर उन्हें आसानी से सजाने की अनुमति देता है। (केवल उन गुणों को देखें जो कम से कम छिपे हुए मानचित्र हैं)।

टेस्ट ड्राइव डिज़ाइन का उपयोग करना बहुत अच्छी युक्ति है - यानी परीक्षण पहले और फिर कार्यान्वयन लिखें। यह आपको डिजाइनर की बजाय यूएसर्स की तरह सोचने के लिए मजबूर करता है, जो अंततः एक बेहतर एपीआई की ओर ले जाएगा।

Answer 5

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

जनरल सलाह

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

डिजाइन सलाह

• डिजाइन और समानांतरवाद के लिए परीक्षण। इन दिनों अधिकांश ढांचे का उपयोग समानांतर प्रसंस्करण गतिविधि के कुछ (और अक्सर बहुत) के साथ अनुप्रयोग बनाने के लिए किया जाता है। वेब अनुप्रयोगों में उपयोग किए जाने वाले ढांचे, विशेष रूप से, सावधानीपूर्वक विचार की आवश्यकता है कि कितनी बहुप्रचारित पहुंच उन्हें प्रभावित करेगी। मेरे द्वारा अनुसरण किए जाने वाले कुछ सामान्य सिद्धांत हैं:
  • जब संभव हो तो ताले से बचें। जब संभव नहीं है, .NET लॉक (...) कथन के बजाय स्पष्ट लॉकिंग ऑब्जेक्ट्स का उपयोग करें।
  • साझा वस्तुओं के लिए रीडर/राइटर ताले का उपयोग करें जो लिखित से अधिक बार पढ़े जाते हैं।
• परतों में डिजाइन कार्यक्षमता। बड़े ढांचे के लिए, यह न केवल कार्यक्षमता को कम करने में मदद करता है बल्कि उपयोगकर्ताओं को वास्तव में आपके ढांचे के हिस्से का अधिक आसानी से उपयोग करने की अनुमति देता है।
• .NET 2.0 और ऊपर के उपयोग के लिए इच्छित ढांचे के लिए, जेनेरिक संग्रह का उपयोग करें! किसी वस्तु [], ArrayList या Hashtable में संग्रहीत किए जाने के बारे में तर्क करना बेहद मुश्किल है ... विशेष रूप से एक बड़े ढांचे में जहां ऐसे संग्रह आंतरिक रूप से पारित होते हैं।
• सार्वजनिक इंटरफ़ेस में ऑब्जेक्ट या ऑब्जेक्ट [] का उपयोग करने से बचें ... यह एक ढांचे में बुरा है और यह बग और रखरखाव की समस्याओं का एक प्रमुख कारण है। आप लगभग हमेशा इंटरफ़ेस ढूंढ सकते हैं या इसके स्थान पर जेनेरिक का उपयोग कर सकते हैं। उन दुर्लभ मामलों में आप दस्तावेज नहीं कर सकते हैं, दस्तावेज बिल्कुल जो आप पारित होने या बाहर होने की उम्मीद करते हैं ... और इसके लिए ज़ोर दें।
• विरासत में एकत्रीकरण पसंद करते हैं। जबकि विरासत एक उपयोगी और शक्तिशाली अवधारणा है, ढांचे लेखकों अक्सर उपयोग या दुरुपयोग पर अक्सर उपयोग करते हैं। सावधानी से सोचें कि विरासत वास्तव में एक डिजाइन समस्या को हल करने के लिए सही उपकरण है या नहीं।
• जब संभव हो तो प्रकार के प्रकार और रनटाइम प्रकार की जांच से बचें। ये आमतौर पर मेरे अनुभव में एक डिजाइन-गंध हैं। बहुत सारे कास्टिंग इंगित करते हैं कि आप इंटरफेस, जेनेरिक, या जेनेरिक बाधाओं का प्रभावी ढंग से लाभ नहीं उठा रहे हैं। यह आपके ढांचे का उपयोग करने के तरीके के रूप में डेवलपर्स के हिस्से पर बग और भ्रम पैदा कर सकता है।
• कॉलर्स को यथासंभव रणनीतियों का उपयोग करके कार्यक्षमता इंजेक्ट करने दें। कुछ प्रकार के विशेषज्ञता के लिए विरासत अधिक है। समर्थन कार्यों के स्तर के साथ .NET पारिस्थितिकी में नागरिकों के रूप में मिलता है, आपको उपभोक्ताओं को प्रदान की जाने वाली कार्यक्षमता को विशेषज्ञता देने के लिए उन्हें (लैम्बडा या प्रतिनिधियों के रूप में) उपयोग करना चाहिए।

कार्यान्वयन सलाह

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