रॉबर्ट सी मार्टिन हमेशा चीज़ों का वर्णन करने का एक नहीं बल्कि अस्पष्ट तरीका था। , "अभिवाही बनाम अपवाही युग्मन" ओह - उनके अंक हमेशा बहुत अच्छे हैं लेकिन गूढ़ रहस्य का एक सा की आवश्यकता होती है! जिस तरह मार्टिन लिखते हैं बारे में एक और बात यह है कि यह हमेशा एक तरह से वर्णनात्मक और आदेशात्मक ("होगा" या "चाहिए"?)
"स्थिरता"
पहले यह समझने के लिए कि मार्टिन को परिभाषित करता है महत्वपूर्ण है "के बीच धुंधला है स्थिरता "। उन्होंने अभिवाही और अपवाही कपलिंग्स एक स्थिरता मीट्रिक उपज के मामले में यह परिभाषित करता है:
instability = efferent/(efferent + afferent)
"अभिवाही" और "अपवाही" इस तरह के अस्पष्ट शब्द हैं। सादगी के लिए, आइए "अपरिपक्व युग्मन" के लिए "आउटगोइंग निर्भरता" "अपरिपक्व युग्मन" और "आने वाली निर्भरताओं" के स्थान पर उपयोग करें।
instability = outgoing/(outgoing + incoming)
यह बहुत ज्यादा परिवर्तन की संभावना से तलाक है, और परिवर्तन की कठिनाई से कोई लेना देना सब कुछ है: तो हम इस किया है। इस परिभाषा के अनुसार, भ्रमित करने के रूप में, एक "स्थिर" पैकेज अभी भी हर समय बदल सकता है (हालांकि यह बुरा होगा और वास्तव में प्रबंधन करना मुश्किल होगा)।
यदि आपको उपर्युक्त सूत्र के साथ शून्य त्रुटि से विभाजित मिलता है, तो आपके पैकेज का उपयोग न तो किया जा रहा है और न ही कुछ भी उपयोग कर रहा है।
स्थिर सिद्धांत
निर्भरता संदर्भ में एसएपी के बारे में मार्टिन बिंदु समझने के लिए, यह SDP (स्थिर निर्भरता सिद्धांत) के साथ शुरू करने के लिए आसान है। यह कहता है:
पैकेजों के बीच निर्भरता पैकेज की स्थिरता की दिशा में होनी चाहिए। एक पैकेज केवल पैकेज पर निर्भर होना चाहिए जो इससे अधिक स्थिर है।
यह समझना बहुत आसान है। आने वाली निर्भरताओं की संख्या (और जटिलता) के साथ एक डिजाइन कैस्केड को बदलने की लागत। शायद बड़े पैमाने पर कोडबेस में काम करने वाले किसी भी व्यक्ति ने इस सुंदरता की सराहना कर सकते हैं जहां एक केंद्रीय डिजाइन परिवर्तन कोडबेस में 10,000 वास्तव में जटिल भागों को तोड़ने के इच्छुक हो सकता है।
तो निर्भरताओं को उन हिस्सों की ओर प्रवाह करना चाहिए जो अपरिवर्तनीय, दृढ़ता से जड़ें, अविश्वसनीय हैं, जैसे कि इसकी पत्तियों से इसकी पत्तियों की तरफ बहने वाले पेड़ की तरह।
स्थिरता मैट्रिक्स कि जड़ों फोड़ा शून्य अपवाही कपलिंग्स (शून्य निवर्तमान निर्भरता) करने के लिए नीचे होना चाहिए। यही है, यह स्थिर "रूट" पैकेज किसी और चीज पर निर्भर नहीं होना चाहिए। दूसरे शब्दों में, यह बाहरी दुनिया से पूरी तरह से स्वतंत्र होना चाहिए। यह विशेषता है जो मार्टिन के मेट्रिक्स के अनुसार "अधिकतम स्थिरता" को परिभाषित करती है: कुल आजादी।
Maximum independence = "stable root" (as I'm calling it)
Maximum dependence = "unstable leaf" (as I'm calling it)
पूरी तरह से स्वतंत्र, अल्ट्रा स्थिर जड़ डिजाइन इस तरह का देखते हुए, कैसे हम अभी भी वापस लचीलापन है जहाँ हम आसानी से इंटरफ़ेस/डिजाइन को प्रभावित किए बिना विस्तार करने और इसके कार्यान्वयन को बदल सकते हैं का एक स्तर हासिल कर सकते हैं? और यहीं कपोल-कल्पना में आते है।
स्थिर चीजें सिद्धांत
चीजें हमें इंटरफेस/डिजाइन से कार्यान्वयन दसगुणा अनुमति देते हैं।
और इस तरह, यहाँ स्थिर कपोल-कल्पना सिद्धांत आता है:
पैकेज अधिकतम स्थिर अधिकतम सार होना चाहिए रहे हैं। अस्थिर पैकेज ठोस होना चाहिए। पैकेज की अमूर्तता इसकी स्थिरता के अनुपात में होनी चाहिए।
विचार है, के रूप में, एसडीपी द्वारा कहा गया, जबकि अभी भी परिवर्तन जो अमूर्त के माध्यम से मूल डिजाइन को प्रभावित नहीं करते के लिए लचीलेपन की एक डिग्री बनाए रखने इन केंद्रीय जड़ डिजाइन अल्ट्रा स्थिर होने की अनुमति है।
एक साधारण उदाहरण के रूप में, कुछ इंजन के दिल में एक सॉफ्टवेयर विकास किट पर विचार करें और दुनिया भर में प्लगइन डेवलपर्स द्वारा उपयोग किया जाता है। परिभाषा के अनुसार, इस एसडीके को कम से कम या आउटगोइंग निर्भरताओं के खिलाफ कई आने वाली निर्भरताओं (इन सभी प्लगइन डेवलपर्स का उपयोग करके) के संयोजन के कारण एक बहुत स्थिर डिजाइन होना होगा (एसडीके थोड़ा और निर्भर करता है)। यह सिद्धांत सुझाव देगा कि स्थिर इंटरफ़ेस को प्रभावित किए बिना परिवर्तन के लिए अधिकतम लचीलापन रखने के लिए इसके इंटरफेस सार होना चाहिए।
"मामूली सार" यहाँ एक सार आधार वर्ग हो सकता है। "अधिकतम रूप से अमूर्त" एक शुद्ध इंटरफ़ेस होगा।
कंक्रीट
दूसरा पहलू पर, सार के साथ ठोस के लिए एक की जरूरत है। अन्यथा एक अमूर्तता के लिए कार्यान्वयन प्रदान करने के लिए कुछ भी नहीं होगा। तो यह सिद्धांत यह भी सुझाव देता है कि ठोस भागों को अस्थिर भागों (चाहिए?) होना चाहिए। यदि आप इसे एक पेड़ (सामान्य प्रोग्रामिंग पेड़ से उलटा) के रूप में कल्पना करते हैं, तो पत्तियों से जड़ तक नीचे बहने वाली निर्भरताओं के साथ, पत्तियां सबसे ठोस होनी चाहिए, जड़ों को सबसे अमूर्त होना चाहिए।
पत्तियों में आमतौर पर सबसे अधिक आउटगोइंग निर्भरताएं होती हैं (उन सभी शाखाओं और जड़ों के बाहर की चीजों पर निर्भरताएं), जबकि उनके पास शून्य आने वाली निर्भरताएं होंगी (कुछ भी उन पर निर्भर नहीं होगा)। जड़ें विपरीत होंगी (सबकुछ उन पर निर्भर करता है, वे कुछ भी नहीं पर निर्भर करते हैं)।
इस प्रकार मैं मार्टिन के विवरण को समझने आया हूं। उन्हें समझना मुश्किल है और मैं कुछ हिस्सों में बंद हो सकता हूं।
सभी मामलों में
निश्चित रूप से स्थिरता की परवाह किए बिना हम कपोल-कल्पना पर निर्भर करता है और ठोस कार्यान्वयन छुपा होना चाहिए?
शायद आप संस्थाओं के मामले में और सोच रहे हैं। किसी इकाई के लिए एक अमूर्त इंटरफ़ेस को अभी भी ठोस कार्यान्वयन की आवश्यकता होगी। ठोस भाग अस्थिर हो सकता है, और इसी तरह से बदलना आसान होगा क्योंकि कुछ भी इस पर निर्भर नहीं है (कोई अपरिपक्व युग्मन नहीं)। अमूर्त हिस्सा स्थिर होना चाहिए क्योंकि कई संभावित रूप से इस पर निर्भर हो सकते हैं (आने वाली निर्भरताओं, बहुत कम या कोई आउटगोइंग निर्भरता), और इसलिए इसे बदलना मुश्किल होगा।
उसी समय, यदि आप एप्लिकेशन पैकेज जैसे अधिक निर्भर पैकेज तक अपना रास्ता काम करते हैं, जहां आपके आवेदन के लिए आपका मुख्य प्रवेश बिंदु है जहां सबकुछ एक साथ इकट्ठा होता है, तो यहां सभी इंटरफेस को अक्सर बढ़ाने के लिए परिवर्तन की कठिनाई, और अभी भी कहीं और ठोस (अस्थिर) कार्यान्वयन की आवश्यकता को स्थानांतरित कर देगी। किसी कोडबेस में किसी बिंदु पर, ठोस भागों में निर्भरता होनी चाहिए, अगर केवल एक अमूर्त इंटरफ़ेस के लिए उपयुक्त ठोस कार्यान्वयन का चयन करना है।
सार करने के लिए या नहीं सार
को
अगर कोई बल्कि concretes से कपोल-कल्पना पर निर्भर करता है के लिए किसी भी नुकसान (मुझे लगता है, कि लाभ outweighs) जानता है कि मैं सोच रहा था।
प्रदर्शन दिमाग में आता है। आमतौर पर अवशोषण में गतिशील प्रेषण के रूप में किसी प्रकार की रनटाइम लागत होती है, उदाहरण के लिए, जो शाखा गलतफहमी के लिए अतिसंवेदनशील हो जाती है। मार्टिन के बहुत सारे लेखन शास्त्रीय ऑब्जेक्ट उन्मुख प्रतिमानों के आसपास घूमते हैं। इसके अलावा, आम तौर पर ओओपी एकवचन इकाई प्रकार के स्तर पर चीजों को मॉडल करना चाहता है। चरम स्तर पर, यह एक छवि के एक पिक्सेल को अपने स्वयं के संचालन के साथ एक अमूर्त इंटरफेस में बनाना चाह सकता है।
मेरे क्षेत्र में, मैं डेटा-उन्मुख डिज़ाइन मानसिकता वाले इकाई-घटक सिस्टम का उपयोग करता हूं। इस प्रकार की शास्त्रीय ओओपी दुनिया उल्टा है। संरचनाओं को अक्सर एक साथ कई इकाइयों के लिए डेटा एकत्र करने के लिए डिज़ाइन किया गया है, जिसमें डिज़ाइन मानसिकता के साथ इष्टतम मेमोरी लेआउट (मानव के लिए तार्किक रूप से मशीन के लिए डिज़ाइनिंग) की तलाश है। संस्थाओं को घटकों के संग्रह के रूप में डिज़ाइन किया गया है, और डेटा को डेटा-उन्मुख मानसिकता का उपयोग करके कच्चे डेटा के रूप में मॉडलिंग किया जाता है। इंटरफ़ेस अभी भी उन घटकों के लिए सार प्राप्त करते हैं जो घटकों को संसाधित करते हैं, लेकिन अवशोषणों को थोक में चीजों को संसाधित करने के लिए डिज़ाइन किया गया है, और निर्भरता सिस्टम से केंद्रीय घटकों तक बहती हैं जो थोड़ी सी में अमूर्त नहीं हैं।
यह गेम इंजनों में नियोजित एक बहुत ही आम तकनीक है और यह प्रदर्शन और लचीलापन के मामले में बहुत अधिक क्षमता प्रदान करता है। फिर भी यह ऑब्जेक्ट उन्मुख प्रोग्रामिंग पर मार्टिन स्थानों पर केंद्रित फोकस के प्रकार के विपरीत है, क्योंकि यह समग्र रूप से ओओपी से मजबूत प्रस्थान है।
क्या यह प्रोग्रामर एसई के लिए बेहतर नहीं है? – usr
धन्यवाद, वहां पोस्ट करेंगे और यहां से हटा देंगे। – SteveCallender
@SteveCallender एसई से एक नए प्रश्न के लिए यहां एक लिंक पोस्ट करें :) लेकिन आम तौर पर मुझे नहीं लगता कि आप इसे यहां क्यों नहीं छोड़ सकते हैं –