"निचले" एप्लिकेशन परतों के लिए "उच्च" लोगों के बारे में पता नहीं होना एक अच्छा विचार क्यों है?

Question

एक सामान्य (अच्छी तरह से डिज़ाइन किया गया) MVC वेब ऐप में, डेटाबेस को मॉडल कोड के बारे में पता नहीं होता है, मॉडल कोड को कंट्रोलर कोड की जानकारी नहीं होती है, और कंट्रोलर कोड को व्यू कोड के बारे में पता नहीं होता है। (मुझे लगता है कि आप हार्डवेयर के रूप में भी नीचे शुरू कर सकते हैं, या शायद आगे भी, और पैटर्न समान हो सकता है।)

दूसरी दिशा में जा रहे हैं, आप केवल एक परत नीचे जा सकते हैं। दृश्य नियंत्रक से अवगत हो सकता है लेकिन मॉडल नहीं; नियंत्रक मॉडल से अवगत हो सकता है लेकिन डेटाबेस से नहीं; मॉडल डेटाबेस से अवगत हो सकता है लेकिन OS नहीं। (गहरी कुछ भी शायद अप्रासंगिक है।)

मैं सहजता से समझ सकता हूं कि यह एक अच्छा विचार क्यों है लेकिन मैं इसे स्पष्ट नहीं कर सकता। एक अच्छा विचार रखने की यह अप्रत्यक्ष शैली क्यों है?

Comments

शायद यह इसलिए है क्योंकि डेटा डेटाबेस से "व्यू" तक आता है। यह डेटाबेस में "शुरू" होता है और दृश्य में "आता है"। डेटा "यात्रा" के रूप में परत जागरूकता विपरीत दिशा में जाती है। मुझे "उद्धरण" का उपयोग करना पसंद है।

— जेसन स्वेट

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

— जिमी हॉफ

मुझे नहीं लगता कि नियंत्रक के बारे में जानकारी के लिए अधिकांश मामलों में यह अच्छा अभ्यास है। चूंकि कंट्रोलर्स लगभग हमेशा व्यू के बारे में जानते हैं, कंट्रोलर के बारे में पता होना एक सर्कुलर रेफरेंस

— एमी ब्लेंकशिप

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

— केश विन्यास

स्पष्ट रूप से एक दृश्य दृढ़ता से टाइप किए गए दृश्य मॉडल से अवगत है।

— DazManCat

Answer 1

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

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

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

Comments

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

— थॉमस बोनी

यह उन लोगों के लिए पढ़ना आवश्यक है जो सोचते हैं कि पूर्ण डिकॉउलिंग के लिए प्रयास करना आदर्श है, लेकिन यह समझ नहीं सकता कि यह काम क्यों नहीं करता है।

— रॉबर्ट हार्वे

खैर, @Andreas, वहाँ हमेशा मेल है ।

— टीआरआईजी

मुझे लगता है कि "समझने में आसान" पर्याप्त नहीं है। यह कोड को संशोधित, विस्तारित और बनाए रखना आसान बनाने के बारे में भी है।

— माइक वेलर

@Peri: ऐसा कानून मौजूद है, en.wikipedia.org/wiki/Law_of_Demeter देखें । आप इससे सहमत हैं या नहीं, यह दूसरी बात है।

— माइक चेम्बरलेन

Answer 2

मूल प्रेरणा यह है: आप एक पूरी परत को चीर कर एक पूरी तरह से अलग (फिर से लिखे गए) और NOBODY SHOULD (BE ABLE TO) के स्थान पर विकल्प का चयन कर सकते हैं।

सबसे स्पष्ट उदाहरण नीचे की परत को चीर रहा है और एक अलग को प्रतिस्थापित कर रहा है। यह तब होता है जब आप हार्डवेयर के सिमुलेशन के खिलाफ ऊपरी परत (ओं) को विकसित करते हैं, और फिर वास्तविक हार्डवेयर में स्थानापन्न करते हैं।

अगला उदाहरण है जब आप एक मध्य परत को चीरते हैं और एक अलग मध्य परत को प्रतिस्थापित करते हैं। एक ऐसे अनुप्रयोग पर विचार करें जो एक प्रोटोकॉल का उपयोग करता है जो RS-232 पर चलता है। एक दिन, आपको प्रोटोकॉल के एन्कोडिंग को पूरी तरह से बदलना होगा, क्योंकि "कुछ और बदल गया"। (उदाहरण: सीधे ASCII एन्कोडिंग से ASCII धाराओं के रीड-सोलोमन एन्कोडिंग पर स्विच करना, क्योंकि आप डाउनटाउन LA से मरीना डेल रे के लिए एक रेडियो लिंक पर काम कर रहे थे, और अब आप एक एलए की जांच के लिए यूरोपा की परिक्रमा करते हुए डाउनटाउन से रेडियो लिंक पर काम कर रहे हैं , बृहस्पति के चंद्रमाओं में से एक, और उस लिंक को बहुत बेहतर फॉरवर्ड त्रुटि सुधार की आवश्यकता है। "

इस कार्य को करने का एकमात्र तरीका यह है कि यदि प्रत्येक परत ऊपर की परत को एक ज्ञात, परिभाषित इंटरफ़ेस निर्यात करती है, और नीचे की परत को एक ज्ञात, परिभाषित इंटरफ़ेस की अपेक्षा करती है।

अब, यह वास्तव में ऐसा नहीं है कि निचली परतें ऊपरी परतों के बारे में कुछ भी नहीं जानती हैं। बल्कि, जो निचली परत जानता है, वह यह है कि इसके ठीक ऊपर की परत उसके परिभाषित इंटरफेस के अनुसार ठीक काम करेगी। यह अधिक कुछ नहीं जान सकता है, क्योंकि परिभाषा के अनुसार परिभाषित इंटरफ़ेस में ऐसा कुछ भी नहीं है जो नोट के बिना परिवर्तन के अधीन है।

RS-232 परत को यह नहीं पता है कि यह ASCII, रीड-सोलोमन, यूनिकोड (अरबी कोड पेज, जापानी कोड पेज, रिगेलियन बीटा कोड पेज), या क्या चल रहा है। यह सिर्फ यह जानता है कि इसे बाइट्स का एक क्रम मिल रहा है और यह उन बाइट्स को एक पोर्ट पर लिख रहा है। अगले हफ्ते, वह कुछ अलग पूरी तरह से अलग बाइट्स का एक अलग अनुक्रम प्राप्त कर सकता है। वह परवाह नहीं करता है। वह बस बाइट्स ले जाता है।

स्तरित डिजाइन का पहला (और सबसे अच्छा) अन्वेषण है दिक्जस्त्र का क्लासिक पेपर "द मल्टीप्रोग्रामिंग सिस्टम की संरचना" । इस व्यवसाय में पढ़ना आवश्यक है।

Comments

यह सहायक है, और लिंक के लिए धन्यवाद। काश मैं दो उत्तरों को सर्वश्रेष्ठ के रूप में चुन पाता। मैंने मूल रूप से एक सिक्का अपने सिर में फँसाया और दूसरे को उठाया, लेकिन मैंने अभी भी तुम्हारा उत्थान किया है।

— जेसन स्वेट

उत्कृष्ट उदाहरणों के लिए +1। मुझे JRS द्वारा दी गई व्याख्या पसंद है

— ViSu

@JasonSwett: अगर मैंने सिक्का फ़्लिप किया था, तो मैंने उस उत्तर को नामित करने तक उसे फ़्लिप किया था! ^ ^ जॉन को +1।

— ओलिवियर दुलक

मैं इससे कुछ हद तक असहमत हूं, क्योंकि आप शायद ही कभी बिजनेस रूल की परत को चीर कर दूसरे के साथ स्वैप करना चाहते हों। व्यवसाय नियम UI या डेटा एक्सेस तकनीकों की तुलना में बहुत धीरे-धीरे बदलते हैं।

— एंडी

डिंग डिंग डिंग !!! मुझे लगता है कि आप जिस शब्द की तलाश कर रहे थे वह ou डिकॉउलिंग ’है। यही अच्छा एपीआई है। एक मॉड्यूल के सार्वजनिक इंटरफेस को परिभाषित करना ताकि इसे सार्वभौमिक रूप से उपयोग किया जा सके।

— इवान प्लाइस

Answer 3

क्योंकि उच्च स्तर हो सकता है बदल जाएगा।

जब ऐसा होता है, तो आवश्यकताओं में परिवर्तन के कारण, नए उपयोगकर्ता, विभिन्न तकनीक, एक मॉड्यूलर (यानी अप्रत्यक्ष रूप से स्तरित) अनुप्रयोग को कम रखरखाव की आवश्यकता होती है और नई आवश्यकताओं को पूरा करने के लिए अधिक आसानी से अनुकूलित किया जाना चाहिए।

Answer 4

मुझे लगता है कि मुख्य कारण यह है कि यह चीजों को और अधिक मजबूती से युग्मित करता है। बाद में मुद्दों में भाग लेने की अधिक संभावना युग्मन को तंग करता है। इस लेख को और अधिक जानकारी देखें: युग्मन

यहाँ एक अंश है:

नुकसान

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

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

Answer 5

IMO, यह बहुत सरल है। आप ऐसी किसी चीज़ का फिर से उपयोग नहीं कर सकते हैं जो उस संदर्भ का संदर्भ देती है जिसका वह उपयोग करता है।

Answer 6

परतों में दो-तरफ़ा निर्भरता नहीं होनी चाहिए

एक स्तरित वास्तुकला के फायदे हैं कि परतें स्वतंत्र रूप से उपयोग करने योग्य होनी चाहिए:

• आपको निचली परत को बदलने के बिना पहले एक के अलावा एक अलग प्रस्तुति परत बनाने में सक्षम होना चाहिए (जैसे मौजूदा वेब इंटरफ़ेस के अलावा एपीआई परत का निर्माण)
• आपको शीर्ष परत को बदलने के बिना, निचली परत को बदलने या अंत में बदलने में सक्षम होना चाहिए

ये स्थितियां मूल रूप से सममित हैं । वे समझाते हैं कि आम तौर पर केवल एक निर्भरता दिशा होना बेहतर है, लेकिन जो नहीं ।

निर्भरता दिशा को कमांड दिशा का पालन करना चाहिए

इस कारण से कि हम एक शीर्ष डाउन निर्भरता संरचना को पसंद करते हैं क्योंकि शीर्ष ऑब्जेक्ट नीचे की वस्तुओं का निर्माण और उपयोग करते हैं । एक निर्भरता मूल रूप से एक रिश्ता है जिसका अर्थ है "ए बी पर निर्भर करता है अगर ए बी के बिना काम नहीं कर सकता है "। तो अगर A में ऑब्जेक्ट B में ऑब्जेक्ट्स का उपयोग करते हैं, तो यह निर्भरता कैसे जानी चाहिए।

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

जबकि ऊपर से हम विधि मंगलाचरण का उपयोग करते हैं, नीचे से (आमतौर पर) हम घटनाओं का उपयोग करते हैं। ईवेंट निर्भरता को तब भी नीचे जाने की अनुमति देते हैं, जब नियंत्रण इधर-उधर हो जाता है। शीर्ष परत ऑब्जेक्ट्स निचली परत पर घटनाओं की सदस्यता लेते हैं। नीचे की परत को ऊपर की परत के बारे में कुछ भी पता नहीं है, जो प्लग के रूप में कार्य करता है।

उदाहरण के लिए एकल दिशा बनाए रखने के अन्य तरीके भी हैं:

• निरंतरता (एक लैम्ब्डा या एक विधि पर कॉल करने के लिए और एक async विधि के लिए घटना)
• सबक्लासिंग (बी में एक मूल वर्ग के ए में एक उपवर्ग का निर्माण करें जो फिर नीचे की परत में इंजेक्ट किया जाता है, थोड़ा सा प्लगइन की तरह)

Answer 7

मैं अपने दो सेंट जोड़ना चाहूंगा कि मैट फेनविक और किलियन फोथ ने पहले ही समझाया है।

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

तो, एक स्तरित वास्तुकला में, निचली परतें ब्लैक बॉक्स हैं जो शीर्ष पर अमूर्त परतों को लागू करती हैं, जिनमें से ऊपरी परत का निर्माण होता है। यदि एक निचली परत (कहते हैं, परत B) एक ऊपरी परत A का विवरण देख सकती है, तो B अब एक ब्लैक बॉक्स नहीं है: इसका कार्यान्वयन विवरण अपने स्वयं के उपयोगकर्ता के कुछ विवरणों पर निर्भर करता है, लेकिन ब्लैक बॉक्स का विचार यह है कि सामग्री (इसका कार्यान्वयन) अपने उपयोगकर्ता के लिए अप्रासंगिक है!

Answer 8

सिर्फ मनोरंजन के लिए।

चीयरलीडर्स के एक पिरामिड के बारे में सोचो। नीचे की पंक्ति उनके ऊपर की पंक्तियों का समर्थन कर रही है।

अगर उस पंक्ति पर चीयरलीडर नीचे दिख रही है तो वे स्थिर हैं और संतुलित रहेंगी ताकि उसके ऊपर वाले न पड़ें।

अगर वह देखती है कि ऊपर वाला सबको किस कर रहा है, तो वह अपना संतुलन ढीला कर लेगी, जिससे पूरा ढेर नीचे गिर जाएगा।

वास्तव में तकनीकी नहीं है, लेकिन यह एक सादृश्य था जो मुझे लगा कि मदद कर सकता है।

Answer 9

जबकि समझने में आसानी और कुछ हद तक बदली घटक निश्चित रूप से अच्छे कारण हैं एक समान रूप से महत्वपूर्ण कारण (और शायद यही कारण है कि परतों को पहले स्थान पर आविष्कार किया गया था) सॉफ्टवेयर रखरखाव के दृष्टिकोण से है। लब्बोलुआब यह है कि निर्भरता चीजों को तोड़ने की क्षमता का कारण बनती है।

उदाहरण के लिए, मान लीजिए कि A, B. पर निर्भर करता है, क्योंकि कुछ भी A पर निर्भर नहीं करता है, डेवलपर्स बिना किसी चिंता के अपने दिल की सामग्री में A को बदलने के लिए स्वतंत्र हैं, क्योंकि वे A. के अलावा कुछ भी नहीं तोड़ सकते हैं, लेकिन यदि डेवलपर B को बदलना चाहता है, तो कोई भी परिवर्तन बी में बनाया गया है कि संभावित रूप से टूट सकता है। यह शुरुआती कंप्यूटर दिनों में लगातार समस्या थी (संरचित विकास के बारे में सोचें) जहां डेवलपर्स कार्यक्रम के एक हिस्से में बग को ठीक कर देंगे और यह कार्यक्रम के अन्य हिस्सों में जाहिरा तौर पर पूरी तरह से असंबंधित भागों में कीड़े पैदा करेगा। सभी निर्भरता के कारण।

उदाहरण के साथ जारी रखने के लिए, अब मान लीजिए कि B और B पर निर्भर करता है। A. IOW, एक परिपत्र निर्भरता पर निर्भर करता है। अब, कभी भी कहीं भी एक बदलाव किया जाता है जो संभवतः अन्य मॉड्यूल को तोड़ सकता है। बी में एक बदलाव अभी भी ए को तोड़ सकता है, लेकिन अब ए में बदलाव बी को भी तोड़ सकता है।

इसलिए आपके मूल प्रश्न में, यदि आप एक छोटी सी परियोजना के लिए एक छोटी सी टीम पर हैं तो यह सब बहुत अधिक है क्योंकि आप स्वतंत्र रूप से अपने व्हाट्सएप पर मॉड्यूल बदल सकते हैं। हालाँकि, यदि आप एक बड़ी परियोजना पर हैं, यदि सभी मॉड्यूल दूसरों पर निर्भर हैं, तो हर समय एक बदलाव की आवश्यकता होती है जो संभवतः अन्य मॉड्यूल को तोड़ सकता है। एक बड़े प्रोजेक्ट पर, सभी प्रभावों को जानने के लिए यह निर्धारित करना मुश्किल हो सकता है कि आप कुछ प्रभावों को याद करेंगे।

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

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

Comments

+1 मेरे नियोक्ता में हमारे पास वास्तव में आपके पिछले पैराग्राफ के सार का वर्णन करने वाला एक आंतरिक आरेख है, क्योंकि यह उस उत्पाद पर लागू होता है जिस पर मैं काम करता हूं अर्थात आगे आप अपने स्टैक के नीचे जाते हैं परिवर्तन की दर कम होती है (और होनी चाहिए)।

— रॉब

Answer 10

सबसे बुनियादी कारण यह है कि निचली परतों को उच्चतर परतों के बारे में पता नहीं होना चाहिए, यह है कि उच्चतर परतों के कई और प्रकार हैं। उदाहरण के लिए, आपके लिनक्स सिस्टम पर हजारों और हजारों विभिन्न कार्यक्रम हैं, लेकिन वे एक ही सी लाइब्रेरी mallocफ़ंक्शन कहते हैं। तो निर्भरता इन कार्यक्रमों से उस पुस्तकालय तक है।

ध्यान दें कि "निचली परतें" वास्तव में बीच की परतें हैं।

उस एप्लिकेशन के बारे में सोचें जो कुछ डिवाइस चालकों के माध्यम से बाहरी दुनिया के माध्यम से संचार करता है। ऑपरेटिंग सिस्टम बीच में है ।

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

तो, कुछ मायनों में, ऑपरेटिंग सिस्टम वास्तव में आवेदन के नजरिए से एक निचली परत है और संचार केन्द्र का एक प्रकार जहां चीजों को जोड़ने और डेटा उचित रास्ते जाने के लिए बंद किया गया है: आवेदन के नजरिए से। यह एक लचीली सेवा को निर्यात करने के लिए संचार हब के डिजाइन में मदद करता है जिसका उपयोग किसी भी चीज द्वारा किया जा सकता है, और हब में किसी भी उपकरण या एप्लिकेशन विशिष्ट हैक्स को स्थानांतरित करने के लिए नहीं।

Comments

मैं तब तक खुश हूँ जब तक मुझे विशिष्ट CPU पिन पर विशिष्ट वोल्टेज सेट करने के बारे में चिंता करने की ज़रूरत नहीं है :)

— एक CVn

Answer 11

इस प्रश्न के लिए चिंताओं और विभाजन / जीत के दृष्टिकोण को अलग करना एक और स्पष्टीकरण हो सकता है। चिंताओं का विभाजन पोर्टेबिलिटी की क्षमता देता है और कुछ अधिक जटिल आर्किटेक्चर में, यह प्लेटफॉर्म को स्वतंत्र स्केलिंग और प्रदर्शन लाभ देता है।

इस संदर्भ में, अगर आपको लगता है कि 5-स्तरीय तीरंदाजी (क्लाइंट, प्रेजेंटेशन, बिजनेस, इंटीग्रेशन और रिसोर्स टियर) के बारे में तो आर्किटेक्चर के निचले स्तर को उच्च स्तर के तर्क और bussiness के बारे में पता नहीं होना चाहिए और इसके विपरीत। मेरा मतलब निचले स्तर से एकीकरण और संसाधन के स्तर के रूप में है। एकीकरण और वास्तविक डेटाबेस और वेबसर्विसेज (3 पार्टी डेटा प्रदाताओं) में प्रदान किए गए डेटाबेस एकीकरण इंटरफेस संसाधन स्तरीय के अंतर्गत आता है। तो मान लीजिए कि आप अपने MySQL डेटाबेस को NoSQL दस्तावेज़ DB में बदल सकते हैं जैसे कि MangoDB जैसे स्केलेबिलिटी या जो भी हो।

इस दृष्टिकोण में, bussiness tier परवाह नहीं करता है कि एकीकरण स्तरीय संसाधन द्वारा कनेक्शन / ट्रांसमिशन कैसे प्रदान करता है। यह केवल इंटीग्रेशन टियर द्वारा प्रदान की गई डेटा एक्सेस ऑब्जेक्ट की तलाश करता है। इसे और अधिक परिदृश्यों तक विस्तारित किया जा सकता है लेकिन मूल रूप से, चिंताओं का अलग होना इसके लिए नंबर एक कारण हो सकता है।

Answer 12

किलियन फोथ के उत्तर पर विस्तार करते हुए, लेयरिंग की यह दिशा एक दिशा से मेल खाती है जिसमें एक मानव एक प्रणाली की खोज करता है।

कल्पना कीजिए कि आप लेयर्ड सिस्टम में बग को ठीक करने के लिए नए डेवलपर हैं।

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

इसीलिए टॉप-डाउन लेयर कनेक्शन होना आवश्यक है। अब, हमारे पास दोनों तरह से कनेक्शन क्यों नहीं हैं?

खैर, आपके पास तीन परिदृश्य हैं कि कैसे बग कभी भी हो सकता है।

यह यूआई कोड में ही हो सकता है, और इसलिए वहां स्थानीयकृत किया जा सकता है। यह आसान है, आपको बस एक जगह खोजने और इसे ठीक करने की आवश्यकता है।

यह UI से की गई कॉल के परिणामस्वरूप सिस्टम के अन्य हिस्सों में हो सकता है। जो मध्यम रूप से कठिन है, आप कॉल के एक पेड़ को ट्रेस करते हैं, एक जगह पाते हैं जहां त्रुटि होती है, और इसे ठीक करें।

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

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

लेयरिंग एक उपकरण है, और मुख्य रूप से मौजूदा सिस्टम का समर्थन करने वाले डेवलपर्स के उद्देश्य से है। खैर, परतों के बीच संबंध भी दर्शाते हैं।

Answer 13

एक अन्य कारण मैं यहां स्पष्ट रूप से उल्लेख करना चाहूंगा कि कोड पुन: प्रयोज्य है । हमारे पास पहले से ही RS232 मीडिया का उदाहरण है जो प्रतिस्थापित हो जाता है, जिससे हम एक कदम आगे बढ़ सकते हैं ...

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

तो आप क्या करना शुरू कर देंगे - जब तक आप एक ही चीज़ को बार-बार करने के बहुत बड़े प्रशंसक नहीं हैं - इन चीजों के लिए पुन: प्रयोज्य परतें लिखना है।

मान लें कि आपको मोदाब उपकरणों के लिए 5 ड्राइवर लिखने हैं। उनमें से एक मोडबस टीसीपी का उपयोग करता है, दो RS485 पर मोडबस का उपयोग करते हैं और बाकी RS232 पर चलते हैं। आप 5 बार मोडबस को फिर से लागू नहीं करने जा रहे हैं, क्योंकि आप 5 ड्राइवर लिख रहे हैं। इसके अलावा आप 3 बार मोडबस को फिर से लागू नहीं करने जा रहे हैं, क्योंकि आपके नीचे 3 अलग-अलग भौतिक परतें हैं।

आप क्या करते हैं, आप एक टीसीपी मीडिया एक्सेस, एक RS485 मीडिया एक्सेस और संभवतः एक RS232 मीडिया एक्सेस लिखते हैं। क्या यह जानना स्मार्ट है कि इस बिंदु पर ऊपर एक मोडबस परत होने वाली है? शायद ऩही। अगला ड्राइवर जिसे आप कार्यान्वित करने जा रहे हैं वह ईथरनेट का उपयोग भी कर सकता है लेकिन HTTP-REST का उपयोग कर सकता है। यह शर्म की बात होगी अगर आपको HTTP के माध्यम से संवाद करने के लिए ईथरनेट मीडिया एक्सेस को फिर से लागू करना होगा।

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

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

Comments

पुन: प्रयोज्य पहले से ही स्पष्ट रूप से आधे से अधिक वर्ष पहले पोस्ट किए गए उत्तर

— gnat