दिलचस्प पोस्ट
टैब / ब्राउज़र बंद करने से पहले पुष्टिकरण उपयोगकर्ताओं को एंड्रॉइड ऐप अपडेट के बारे में कैसे जानकारी दें? मैं आर में एक सहसंबंध मैट्रिक्स कैसे बना सकता हूं? अमेज़ॅन क्लाउड सर्वर पर FTP सेट करना मावेन: रिश्तेदार पथ द्वारा एक जार पर निर्भरता जोड़ें Azure वेबसाइट पर विभिन्न स्थानों पर एकाधिक परियोजनाएं प्रकाशित करें मावेन: हस्तलिखित विवरणकर्ता को पढ़ने में असफल क्या मैं आईओएस 5 अधिसूचना केंद्र से अपने ऐप की सूचनाओं को प्रोग्रामेटिक रूप से साफ़ कर सकता हूं? रोगजनक प्लगइन्स लोड नहीं करता है सी # में बेनामी विधि की सदस्यता रद्द करें स्विच के साथ एंड्रॉइड कोडिंग (स्ट्रिंग) कैसे अपनी निजी रजिस्ट्री के बिना एक निजी एनपीएम मॉड्यूल को स्थापित करें? एएसपी.नेट एमवीसी 5 में फेसबुक v2.4 एपीआई से OAuth ExternalLogin कॉलबैक में ईमेल पते पर पहुंचें सरल जावास्क्रिप्ट उलटी गिनती टाइमर के लिए कोड? जावास्क्रिप्ट प्रोटोटाइप क्यों है?

"ढीले युग्मन" क्या है? कृपया उदाहरण दें

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

क्या कोई इस "अवधारणा" और "बाद" कोड (या स्यूडोकोड) को दिखाएगा जो इस अवधारणा को दिखाता है?

Solutions Collecting From Web of ""ढीले युग्मन" क्या है? कृपया उदाहरण दें"

शॉपिंग कार्ट में वस्तुओं का ट्रैक रखने के लिए एक कार्ट शॉपिंग कार्ट का इस्तेमाल करने वाला एक सरल शॉपिंग कार्ट एप्लिकेशन पर विचार करें और खरीदारी के लिए एक ऑर्डर क्लास खरीदें। ऑर्डर को गाड़ी में सामग्री के कुल मूल्य को निर्धारित करने की जरूरत है, ऐसा ऐसा कर सकता है:

कड़े युग्म उदाहरण:

public class CartEntry { public float Price; public int Quantity; } public class CartContents { public CartEntry[] items; } public class Order { private CartContents cart; private float salesTax; public Order(CartContents cart, float salesTax) { this.cart = cart; this.salesTax = salesTax; } public float OrderTotal() { float cartTotal = 0; for (int i = 0; i < cart.items.Length; i++) { cartTotal += cart.items[i].Price * cart.items[i].Quantity; } cartTotal += cartTotal*salesTax; return cartTotal; } } 

नोटिस कैसे ऑर्डरटोलल विधि (और इस प्रकार ऑर्डर क्लास) CartContents और CartEntry कक्षाओं के कार्यान्वयन के विवरण पर निर्भर करता है। अगर हम डिस्काउंट की अनुमति देने के लिए इस तर्क को बदलने की कोशिश कर रहे थे, तो हमें सभी 3 कक्षाओं को बदलना होगा। इसके अलावा, यदि हम वस्तुओं का ट्रैक रखने के लिए सूची संग्रह का उपयोग करने के लिए बदलते हैं, तो हमें ऑर्डर वर्ग को भी बदलना होगा।

अब ये एक ही काम करने का थोड़ा बेहतर तरीका है:

कम युग्मित उदाहरण:

 public class CartEntry { public float Price; public int Quantity; public float GetLineItemTotal() { return Price * Quantity; } } public class CartContents { public CartEntry[] items; public float GetCartItemsTotal() { float cartTotal = 0; foreach (CartEntry item in items) { cartTotal += item.GetLineItemTotal(); } return cartTotal; } } public class Order { private CartContents cart; private float salesTax; public Order(CartContents cart, float salesTax) { this.cart = cart; this.salesTax = salesTax; } public float OrderTotal() { return cart.GetCartItemsTotal() * (1.0f + salesTax); } } 

तर्क जो कार्ट लाइन आइटम या कार्ट संग्रह के क्रियान्वयन के लिए विशिष्ट है या ऑर्डर केवल उस क्लास के लिए प्रतिबंधित है। इसलिए हम अन्य वर्गों को बदलने के बिना इन कक्षाओं में से किसी के कार्यान्वयन को बदल सकते हैं। हम इस डिजाइन को सुधारने, इंटरफेस आदि को शुरू करने के द्वारा और फिर भी इस decoupling को ले सकते हैं, लेकिन मुझे लगता है कि आप इस बिंदु को देखते हैं।

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

वही , 1: 1, सॉफ्टवेयर विकास के लिए चला जाता है।

मैं एक उदाहरण के रूप में जावा का उपयोग करूँगा। मान लें कि हमारे पास ऐसा वर्ग है जो इस तरह दिखता है:

 public class ABC { public void doDiskAccess() {...} } 

जब मैं क्लास को कॉल करता हूं, तो मुझे इस तरह कुछ करने की आवश्यकता होगी:

 ABC abc = new ABC(); abc. doDiskAccess(); 

अब तक सब ठीक है. अब मान लें कि मेरे पास एक और वर्ग है जो इस तरह दिखता है:

 public class XYZ { public void doNetworkAccess() {...} } 

यह बिल्कुल एबीसी के समान है, लेकिन हम कहते हैं कि यह नेटवर्क पर डिस्क के स्थान पर काम करता है। तो अब हम इस तरह एक प्रोग्राम लिखते हैं:

 if(config.isNetwork()) new XYZ().doNetworkAccess(); else new ABC().doDiskAccess(); 

यह काम करता है, लेकिन यह थोड़ा बोझल है मैं इसे इस तरह एक इंटरफ़ेस के साथ सरल बना सकता हूं:

 public interface Runnable { public void run(); } public class ABC implements Runnable { public void run() {...} } public class XYZ implements Runnable { public void run() {...} } 

अब मेरा कोड इस तरह दिख सकता है:

 Runnable obj = config.isNetwork() ? new XYZ() : new ABC(); obj.run(); 

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

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

क्षमा करें, लेकिन "ढक्कन युग्मन" कोडिंग समस्या नहीं है, यह एक डिजाइन मुद्दा है "ढीले युग्मन" शब्द "उच्च एकता" की वांछनीय अवस्था से संबंधित है, जो विपरीत है लेकिन पूरक है।

ढीला युग्मन का अर्थ है कि अलग-अलग डिजाइन तत्वों का निर्माण किया जाना चाहिए ताकि अन्य डिजाइन तत्वों के बारे में जानना आवश्यक अनावश्यक जानकारी की मात्रा कम हो।

उच्च सामंजस्य "तंग युग्मन" की तरह है, लेकिन उच्च सामंजस्य एक ऐसा राज्य है, जहां डिजाइन तत्वों को वास्तव में एक-दूसरे के बारे में जानने की आवश्यकता होती है ताकि वे एक साथ स्वच्छ और सुंदर ढंग से काम कर सकें।

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

इसे लागू करने के लिए पाठक के लिए एक अभ्यास के रूप में छोड़ दिया है :)।

कड़े युग्मित कोड एक ठोस क्रियान्वयन पर निर्भर करता है। अगर मुझे अपने कोड में तार की एक सूची की आवश्यकता है और मैं इसे इस तरह घोषित करता हूं (जावा में)

 ArrayList<String> myList = new ArrayList<String>(); 

तो मैं ArrayList कार्यान्वयन पर निर्भर हूँ

अगर मैं इसे ढीली युग्मित कोड में बदलना चाहता हूं, तो मैं एक इंटरफ़ेस (या अन्य सार) प्रकार का मेरा संदर्भ बना देता हूं।

 List<String> myList = new ArrayList<String>(); 

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

बेशक, आप पहले घोषणा का उपयोग करके एक ArrayList को इन्स्तांत कर सकते हैं और अपने आप को किसी भी तरीके का उपयोग न करने से रोक सकते हैं जो सूची इंटरफ़ेस का हिस्सा नहीं हैं, लेकिन दूसरे घोषणा का उपयोग करके कंपाइलर आपको ईमानदार रखता है।

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

जवाबों के बीच अंतर की डिग्री से पता चलता है कि यह समझना मुश्किल अवधारणा क्यों होगा, लेकिन इसे उतना ही उतना ही रखे जैसा मैं इसे वर्णन कर सकता हूं:

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

गैर-गतिशील भाषाओं जैसे सी # या जावा इत्यादि के साथ, हम इंटरफेस के माध्यम से इसे पूरा करते हैं। तो कहें कि हमारे पास निम्न इंटरफ़ेस है:

 public ICatcher { public void Catch(); } 

और अब कहें कि हमारे पास निम्न कक्षाएं हैं:

 public CatcherA : ICatcher { public void Catch() { console.writeline("You Caught it"); } } public CatcherB : ICatcher { public void Catch() { console.writeline("Your brother Caught it"); } } 

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

 public CatchService { private CatcherA catcher = new CatcherA(); public void CatchService() { catcher.Catch(); } } 

तो CatchService ऐसा करने के लिए निर्धारित किया गया है, लेकिन यह कैचर ए का उपयोग करता है और हमेशा उपयोगकर्ता कैचर ए करता है। इसकी कड़ी मेहनत में कोडित है, इसलिए जब तक कोई तब तक नहीं आ रहा है और इसे रिएक्टर करता है तब तक वहां रहना है।

अब आइए एक अन्य विकल्प लेते हैं, जिसे निर्भरता इंजेक्शन कहा जाता है:

 public CatchService { private ICatcher catcher; public void CatchService(ICatcher catcher) { this.catcher = catcher; catcher.Catch(); } } 

तो CachService instalsiates कि cals निम्न कर सकते हैं:

 CatchService catchService = new CatchService(new CatcherA()); 

या

 CatchService catchService = new CatchService(new CatcherB()); 

इसका मतलब यह है कि कैच सेवा कैचर ए या कैचर बी के लिए कसकर युग्मित नहीं है

इस तरह की ढीली युग्मन सेवाओं के लिए कई अन्य दलदलियां हैं, जैसे कि आईओसी ढांचा आदि का उपयोग।

परिभाषा

अनिवार्य रूप से, युग्मन यह है कि एक वस्तु या वस्तु का सेट किसी अन्य ऑब्जेक्ट या ऑब्जेक्ट के दूसरे सेट पर निर्भर करता है ताकि इसके कार्य को पूरा किया जा सके।

उच्च युग्मन

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

ढीला युग्मन

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

यह एक बहुत ही सामान्य अवधारणा है, इसलिए कोड उदाहरण पूरी तस्वीर नहीं दे रहे हैं

यहां काम करने वाले एक व्यक्ति ने मुझसे कहा, "पैटर्न भग्न की तरह हैं, आप उन्हें देख सकते हैं जब आप वास्तव में करीब ज़ूम करते हैं, और जब आप वास्तुकला स्तर से बाहर निकलते हैं।"

संक्षिप्त विकिपीडिया पेज पढ़ना आपको इस सामान्यता की भावना दे सकता है:

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

जहां तक ​​एक विशिष्ट कोड उदाहरण …

यहाँ एक ढीली युग्मन है जिसे मैंने माइक्रोसॉफ्ट से हाल ही में काम किया है। प्रैक्टिस। कॉमपोज़िटयूआई सामान।

  [ServiceDependency] public ICustomizableGridService CustomizableGridService { protected get { return _customizableGridService; } set { _customizableGridService = value; } } 

यह कोड घोषित कर रहा है कि इस वर्ग की CustomizableGridService पर निर्भरता है सेवा के सही कार्यान्वयन को सीधे संदर्भित करने के बजाय, यह केवल कहता है कि उसे उस सेवा के कुछ कार्यान्वयन की आवश्यकता है फिर रनटाइम पर, सिस्टम उस निर्भरता को हल करता है

अगर यह स्पष्ट नहीं है, तो आप यहां अधिक विस्तृत व्याख्या पढ़ सकते हैं:

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

कल्पना कीजिए कि ABCC CustomizableGridService इकलॉमेमेंटेशन है जो मैं यहां हुक करने का इरादा रखता हूं।

अगर मैं इसे चुनता हूं, तो मैं इसे बाहर कर सकता हूं और इसे XYZ CustomizableGridService, या StubCustomizableGridService के साथ इस निर्भरता के साथ कक्षा में बिल्कुल भी परिवर्तन नहीं कर सकता।

अगर मैंने सीधे ABCCustomizableGridService संदर्भित किया है, तो मुझे उस सेवा / अन्य कार्यान्वयन में स्वैप करने के लिए उस संदर्भ / एस में परिवर्तन करने की आवश्यकता होगी

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

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

कुछ उदाहरण:

  • एप्लिकेशन लाइब्रेरी पर निर्भर करता है। तंग युग्मन के तहत, ओब के नए संस्करणों पर ऐप ब्रेक "DLL Hell" के लिए Google

  • क्लाइंट ऐप एक सर्वर से डाटा पढ़ता है तंग युग्मन के तहत, सर्वर में परिवर्तन क्लाइंट साइड पर फिक्स की आवश्यकता होती है।

  • ऑब्जेक्ट-ओरिएंटेड पदानुक्रम में दो क्लास बातचीत करते हैं तंग युग्मन के तहत, एक वर्ग में परिवर्तन करने के लिए दूसरे वर्ग को मैच के लिए अद्यतन करने की आवश्यकता होती है।

  • कई कमांड लाइन टूल एक पाइप में संचार करते हैं। यदि वे कसकर युग्मित हैं, तो एक कमांड लाइन टूल के संस्करण में हुए बदलावों से टूल में त्रुटियों का कारण होगा जो इसके आउटपुट को पढ़ते हैं।

सरल भाषा में, शिथिल रूप से युग्मित होने का मतलब यह है कि यह अन्य घटनाओं पर निर्भर नहीं होता है। यह स्वतंत्र रूप से कार्यान्वित करता है

FormA और FormB के साथ एक विंडोज ऐप पर विचार करें फॉर्मए प्राथमिक रूप है और यह फॉर्मबी दिखाता है कल्पना कीजिए कि FormB को अपने माता पिता को वापस डेटा पास करने की आवश्यकता है।

यदि आप ऐसा करते हैं:

 class FormA { FormB fb = new FormB( this ); ... fb.Show(); } class FormB { FormA parent; public FormB( FormA parent ) { this.parent = parent; } } 

FormB कसकर FormA के लिए युग्मित है FormB के प्रकार FormA से कोई अन्य अभिभावक नहीं हो सकता है

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

आरपी

जब वे एक-दूसरे के ठोस क्रियान्वयन पर निर्भर करते हैं, तो दो घटकों को बहुत अधिक युग्मित किया जाता है।

मान लीजिए कि मेरी कक्षा में किसी विधि में कहीं यह कोड है:

 this.some_object = new SomeObject(); 

अब मेरी कक्षा कुछ ऑब्जेक्ट पर निर्भर है, और वे बहुत युग्मित हैं दूसरी तरफ, मान लें कि मेरे पास एक तरीका इंजेक्शन सोइबेज है:

 void InjectSomeObject(ISomeObject so) { // note we require an interface, not concrete implementation this.some_object = so; } 

फिर पहला उदाहरण केवल इंजेक्शन SomeObject का उपयोग कर सकता है यह परीक्षण के दौरान उपयोगी है सामान्य ऑपरेशन के साथ आप भारी, डेटाबेस-उपयोग, नेटवर्क-उपयोग करने वाले कक्षाओं आदि का उपयोग कर सकते हैं। जबकि हल्के, नकली क्रियान्वयन से गुजरने वाले परीक्षण कसकर युग्मित कोड के साथ आप ऐसा नहीं कर सकते

निर्भरता इंजेक्शन कंटेनर का उपयोग करके आप इस कार्य के कुछ हिस्सों को बना सकते हैं आप विकिपीडिया http://en.wikipedia.org/wiki/Dependency_injection पर डि के बारे में अधिक पढ़ सकते हैं।

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

कंप्यूटर विज्ञान में "ढीले युग्मन" के लिए एक और अर्थ है, जिसने यहां किसी के बारे में पोस्ट नहीं किया है, इसलिए … यहाँ जाता है – उम्मीद है कि आप मुझे कुछ वोट देंगे इसलिए यह ढेर के नीचे नहीं खोया जाता है! निश्चित रूप से मेरे उत्तर का विषय प्रश्न के किसी भी व्यापक उत्तर में है … बुद्धि के लिए:

शब्द "ढीले युग्मन" पहले बहुआयामी कॉन्फ़िगरेशन में सीपीयू वास्तुकला के बारे में एक विशेषण के रूप में इस्तेमाल किया गया शब्द के रूप में कंप्यूटिंग में प्रवेश किया। इसका समकक्ष शब्द "तंग युग्मन" है ढीले युग्मन तब होता है जब सीपीयू कई संसाधनों को आम और तंग युग्मन में साझा नहीं करते हैं, जब वे करते हैं।

शब्द "सिस्टम" यहां भ्रमित हो सकता है, कृपया स्थिति को सावधानीपूर्वक पार्स करें।

सामान्यतः, लेकिन हमेशा नहीं, एक हार्डवेयर कॉन्फ़िगरेशन में एकाधिक CPUs जिसमें वे एक सिस्टम (व्यक्तिगत "पीसी" बक्से के रूप में) में मौजूद होते हैं कसकर युग्मित किया जाएगा कुछ उच्च-उच्च-प्रदर्शन प्रणालियों के अपवाद के साथ जो सबसिस्टम हैं जो वास्तव में "सिस्टम्स" में मुख्य मेमोरी साझा करते हैं, सभी विभाज्य प्रणालियां ढीली से जोड़ती हैं

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

सबसे पहले, चूंकि यह सवाल था, ढीले से युग्मित प्रणालियों के कुछ उदाहरण:

  • VaxClusters
  • लिनक्स क्लस्टर

इसके विपरीत, कुछ कड़े युग्म उदाहरण:

  • सैमेट्री-मल्टी प्रसंस्करण (एसएमपी) ऑपरेटिंग सिस्टम – जैसे फेडोरा 9
  • बहु-थ्रेडेड सीपीयू
  • मल्टी कोर सीपीयू

आज के कंप्यूटिंग में, एक समग्र प्रणाली में दोनों ऑपरेटिंग के उदाहरण असामान्य नहीं हैं उदाहरण के लिए, Fedora 9 चलने वाले आधुनिक पेन्टियम दोहरे या क्वाड कोर सीपीयू ले लो – इन कसकर युग्मित कंप्यूटिंग सिस्टम हैं उसके बाद, उनमें से कई को एक ढीला युग्मित लिनक्स क्लस्टर में मिलाएं और अब आपके पास ढीला और कसकर युग्मित कंप्यूटिंग चल रहा है! ओह, आधुनिक हार्डवेयर अद्भुत नहीं है!

कुछ लंबे समय से उत्तर यहां। सिद्धांत बहुत सरल है हालांकि। मैं विकिपीडिया से उद्घाटन वक्तव्य प्रस्तुत करता हूं:

"ढीला युग्मन दो या दो से अधिक प्रणालियों या संगठनों के बीच संबंधों के संबंध में किसी तरह के संबंधों का वर्णन करता है।

लेन-देन के प्रत्येक छोर को अपनी आवश्यकताओं को स्पष्ट बनाता है और दूसरे छोरों के बारे में कुछ धारणाएं होती हैं। "

मैं कोड युग्मन के एक बहुत ही सरल परीक्षण का प्रस्ताव:

  1. कोड का टुकड़ा A कसकर पीस बी के कोड के साथ मिलकर जुड़ा हुआ है, अगर पीस बी में कोई भी संभव संशोधन होता है तो वह सही रखने के लिए टुकड़ा ए में परिवर्तन को मजबूर कर सकता है।

  2. कोड का टुकड़ा A कसकर पीस बी के कोड में युग्मित नहीं है, अगर टुकड़ा बी में कोई भी संभव संशोधन नहीं होता है जो कि टुकड़ा ए के लिए एक आवश्यक परिवर्तन करेगा।

इससे आपको यह सत्यापित करने में मदद मिलेगी कि आपके कोड के टुकड़ों के बीच कितनी युग्मन है। इस ब्लॉग पोस्ट को देखने के लिए तर्क के लिए: http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/

युग्मन का मतलब है कि कैसे एक दूसरे से कसकर अलग-अलग वर्ग जुड़े हुए हैं। कड़े युग्मित वर्गों में बहुत अधिक संख्या में बातचीत और निर्भरताएं हैं।

ढीला युग्मित वर्ग विपरीत होते हैं क्योंकि उनकी निर्भरता एक दूसरे पर रखी जाती है और इसके बजाय एक दूसरे के अच्छी तरह से परिभाषित सार्वजनिक इंटरफेस पर भरोसा करते हैं।

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

संदर्भ: https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/

आप "ढीले युग्मन" की सामान्य अवधारणा के बारे में अधिक पढ़ सकते हैं

संक्षेप में, यह दो वर्गों के बीच संबंध का वर्णन है, जहां हर वर्ग को दूसरे के बारे में बहुत कम जानकारी है और प्रत्येक कक्षा संभवत: ठीक काम करना जारी रखेगी कि अन्य मौजूद है या नहीं और दूसरे के विशेष कार्यान्वयन पर निर्भरता के बिना कक्षा।

जब आप किसी दूसरे वर्ग के new कीवर्ड का इस्तेमाल करते हुए एक कक्षा का एक ऑब्जेक्ट बनाते हैं, तो आप वास्तव में कठोर युग्मन (बुरा व्यवहार) कर रहे हैं, इसके बजाय आपको ढीले युग्मन का उपयोग करना चाहिए जो कि एक अच्छा अभ्यास है

— A.java —

 package interface_package.loose_coupling; public class A { void display(InterfaceClass obji) { obji.display(); System.out.println(obji.getVar()); } } 

— B.java —

 package interface_package.loose_coupling; public class B implements InterfaceClass{ private String var="variable Interface"; public String getVar() { return var; } public void setVar(String var) { this.var = var; } @Override public void display() { // TODO Auto-generated method stub System.out.println("Display Method Called"); } } 

— InterfaceClass —

 package interface_package.loose_coupling; public interface InterfaceClass { void display(); String getVar(); } 

— MainClass —

 package interface_package.loose_coupling; public class MainClass { public static void main(String[] args) { // TODO Auto-generated method stub A obja=new A(); B objb=new B(); obja.display(objb); //Calling display of A class with object of B class } } 

स्पष्टीकरण:

उपरोक्त उदाहरण में, हमारे पास दो कक्षाएं ए और बी हैं I

क्लास बी इंफॉर्मेशन इंटरफ़ेस अर्थात इंटरफ़ेस क्लास

इंटरफ़ेस क्लास बी क्लास के लिए अनुबंध को परिभाषित करता है क्योंकि इंटरफ़ेस क्लास में बी क्लास के अमूर्त तरीके हैं, जो किसी अन्य क्लास द्वारा एक्सेस हो सकते हैं।

क्लास ए में हमारे पास डिस्प्ले मेथड है, जो इंटरफेस क्लास (हमारे मामले में यह बी क्लास है) को लागू करने वाले क्लास के ऑब्जेक्ट को छोड़ सकता है। और कक्षा ए की उस ऑब्जेक्ट मेथड पर क्लास बी की डिस्प्ले () और getVar () कॉल कर रहा है

मेनक्लास में हमने कक्षा ए और बी का उद्देश्य बनाया है और बी कक्षा यानी ऑब्ज़ब का ऑब्जेक्ट पास करके A की डिस्प्ले पद्धति को कॉल किया है। ए के प्रदर्शन पद्धति को बी कक्षा के ऑब्जेक्ट के साथ बुलाया जाएगा।

अब ढीले युग्मन के बारे में बात कर रहे हैं मान लीजिए कि भविष्य में आपको कक्षा बी को एबीसी नाम बदलना होगा, तो आपको कक्षा बी की डिस्प्ले पद्धति में अपना नाम बदलने की ज़रूरत नहीं है, बस नए (एबीसी वर्ग) के ऑब्जेक्ट को बनाएं और इसे मेल क्लास में डिस्प्ले मेथड पर रखें। आपको कक्षा ए में कुछ भी बदलने की ज़रूरत नहीं है

रेफरी: http://p3lang.com/2013/06/loose-coupling-example-using-interface/

शायद सबसे अच्छा रूपक शादी है।

जब आप शादी नहीं कर रहे हैं, तो आप ढीला युग्मित हैं

आप अपने साथी को आसानी से छोड़ सकते हैं

जब आप "शादी" कर रहे हैं, तो आप कसकर युग्मित हैं

उदाहरण के लिए, कुछ देशों में आपको अपने साथी को छोड़ते वक्त गुदा भत्ते का भुगतान करना पड़ता है।

ढीला युग्मन, सामान्य तौर पर, 2 कलाकार एक ही काम के बोझ पर स्वतंत्र रूप से काम करते हैं। इसलिए यदि आपके पास एक ही बैक-एंड डेटाबेस का इस्तेमाल करते हुए 2 वेब सर्वर होते हैं, तो आप कहेंगे कि वे वेब सर्वर ढीले से युग्मित हैं चुस्त युग्मन को एक वेब सर्वर पर 2 प्रोसेसर होने से समझाया जाएगा … उन प्रोसेसर कसकर युग्मित हैं।

आशा है कि कुछ उपयोगी है