सही वास्तुकला

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

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



जब क्लास डिजाइन, मॉड्यूल आर्किटेक्चर, या किसी एप्लिकेशन की विभिन्न परतों की जिम्मेदारी आती है, तो सामंजस्य और युग्मन की अवधारणाएं उनके डिजाइन में निर्णायक भूमिका निभाती हैं। डिजाइन पैटर्न के "पिता" क्रिस्टोफर अलेक्जेंडर ने लिखा है कि एक प्रणाली को डिकम्पोज करने में मुख्य कार्य दो शर्तों को पूरा करना है: (1) घटकों के अंदर कनेक्शन को अधिकतम करना ( उच्च आंतरिक आसंजन , तंग आंतरिक सामंजस्य) और (2) घटकों के बीच कनेक्शन को कम करना ( कम बाहरी युग्मन)।

नोट
आप इस तरह के एक अद्वितीय अवधारणा के उद्भव के इतिहास के बारे में लेख में डिजाइन पैटर्न के रूप में पढ़ सकते हैं: डिजाइन पैटर्न। सफलता की कहानी ।

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



चित्र 1 - और इस चमत्कार का परीक्षण कैसे करें? लेकिन वास्तविक जीवन में कई बार अधिक संबंध हो सकते हैं।

परिषद
एक अच्छे वर्ग के डिजाइन के "लिटमस टेस्ट" के रूप में कक्षा के "परीक्षणनीयता" के सिद्धांत का उपयोग करें। यहां तक ​​कि अगर आप परीक्षण कोड की एक भी पंक्ति नहीं लिखते हैं (हालांकि व्यर्थ!), 90% मामलों में इस प्रश्न का उत्तर समझने में मदद करेगा कि "अच्छा" या "बुरा" सब कुछ इसके डिजाइन के साथ है।

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

वास्तु संबंधी समस्याओं को हल करते समय, जैसे वितरित अनुप्रयोगों के निर्माण के लिए एक मंच चुनना, एक यूआई फ्रेमवर्क या डेटा एक्सेस लेयर का आर्किटेक्चर चुनना, यह अपने आप से एक और सवाल पूछने के लिए उचित है: "क्या होगा यदि अब किया गया निर्णय गलत है?" या "सामान्य रूप से, क्या मुझे चाहिए? अभी अंतिम निर्णय लें? ”

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

अच्छी वास्तुकला को सबसे छोटे विस्तार से नहीं सोचा जाना चाहिए; एक अच्छी वास्तुकला को अच्छी तरह से समझा जाना चाहिए कि यह समझने के लिए कि आवेदन के एक हिस्से में कितना वास्तुशिल्प त्रुटियां पूरी तरह से अलग-अलग असंबंधित मॉड्यूल को तोड़ देगा।

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

विषय से विचलन। बॉब मार्टिन द्वारा स्वच्छ वास्तुकला

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

अंतिम ज्ञात लेखकों में से एक, वास्तुकला का विषय बॉब मार्टिन द्वारा उठाया गया था। अपनी प्रस्तुतियों में, साथ ही साथ वास्तुकला में अपने एक पोस्ट में, बॉब ने निम्नलिखित लिखा है: ... अच्छा वास्तुकला महत्वपूर्ण निर्णय लेने की अनुमति देता है ... अच्छी वास्तुकला UNACCEPTED निर्णयों की संख्या को अधिकतम करती है ।

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

नोट
बॉब मार्टिन की प्रस्तुति, जिसका मैंने ऊपर उल्लेख किया है, इस मुद्दे की चर्चा के साथ एक लघु वीडियो यहां पाया जा सकता है । और यहाँ एक ही विषय पर कुछ बॉब पोस्ट हैं: क्लीन आर्किटेक्चर और स्क्रीमिंग आर्किटेक्चर ।

निष्कर्ष

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