ऑब्जेक्ट ओरिएंटेड प्रतिमान में ढीले युग्मन और तंग युग्मन के बीच अंतर क्या है?
जवाबों:
चुस्त युग्मन तब होता है जब वर्गों का एक समूह एक दूसरे पर अत्यधिक निर्भर होता है।
यह परिदृश्य तब पैदा होता है जब एक वर्ग बहुत सारी जिम्मेदारियों को स्वीकार करता है, या जब एक चिंता अपने वर्ग होने के बजाय कई वर्गों में फैल जाती है।
ढीले युग्मन को एक डिजाइन के माध्यम से प्राप्त किया जाता है जो एकल-जिम्मेदारी और चिंताओं को अलग करने को बढ़ावा देता है।
एक शिथिल-युग्मित वर्ग को अन्य (ठोस) वर्गों से स्वतंत्र रूप से उपभोग और परीक्षण किया जा सकता है।
डिकॉउलिंग के लिए उपयोग करने के लिए इंटरफेस एक शक्तिशाली उपकरण है। कक्षाएं अन्य कंक्रीट कक्षाओं के बजाय इंटरफेस के माध्यम से संवाद कर सकती हैं, और कोई भी वर्ग केवल इंटरफ़ेस को लागू करके उस संचार के दूसरे छोर पर हो सकता है।
तंग युग्मन का उदाहरण:
class CustomerRepository
{
private readonly Database database;
public CustomerRepository(Database database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
class Database
{
public void AddRow(string Table, string Value)
{
}
}
ढीली युग्मन का उदाहरण:
class CustomerRepository
{
private readonly IDatabase database;
public CustomerRepository(IDatabase database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
interface IDatabase
{
void AddRow(string Table, string Value);
}
class Database implements IDatabase
{
public void AddRow(string Table, string Value)
{
}
}
एक और उदाहरण यहाँ ।
किसी भी कोड के बिना स्पष्टीकरण
सारांश उदाहरण:
टोपी शरीर के लिए "शिथिल युग्मित" है। इसका मतलब है कि आप व्यक्ति / शरीर में कोई बदलाव किए बिना आसानी से टोपी को उतार सकते हैं। जब आप ऐसा कर सकते हैं तो आपके पास "ढीली युग्मन" है। विस्तार के लिए नीचे देखें।
तंग युग्मन (विस्तृत उदाहरण)
अपनी त्वचा के बारे में सोचो। यह आपके शरीर से चिपका हुआ है। यह एक दस्ताना की तरह फिट बैठता है। लेकिन क्या होगा अगर आप अपनी त्वचा का रंग सफेद से हरे रंग में बदलना चाहते हैं? क्या आप कल्पना कर सकते हैं कि आपकी त्वचा को छीलना, उसे रंगाना और फिर उसे वापस चिपकाने के लिए कितना दर्दनाक होगा? आपकी त्वचा को बदलना मुश्किल है क्योंकि यह कसकर आपके शरीर से जुड़ा होता है। आप आसानी से बदलाव नहीं कर सकते। आपको इसे संभव बनाने के लिए किसी इंसान को मौलिक रूप से नया स्वरूप देना होगा।
- मुख्य बिंदु # 1 : दूसरे शब्दों में, यदि आप त्वचा को बदलना चाहते हैं , तो आप अपने शरीर के डिजाइन को भी बदलना चाहेंगे क्योंकि दोनों एक साथ हैं - वे कसकर युग्मित हैं।
भगवान एक अच्छी वस्तु उन्मुख प्रोग्रामर नहीं थे।
ढीली युग्मन (विस्तृत उदाहरण)
अब सुबह कपड़े पहनने के बारे में सोचो। आपको नीला पसंद नहीं है? कोई समस्या नहीं: आप इसके बजाय एक लाल शर्ट डाल सकते हैं। आप इसे आसानी से और सहजता से कर सकते हैं क्योंकि शर्ट वास्तव में आपके शरीर से उसी तरह से जुड़ी नहीं है जैसे आपकी त्वचा। शर्ट को पता नहीं है या परवाह नहीं है कि यह किस शरीर के साथ चल रहा है । दूसरे शब्दों में, आप वास्तव में अपने शरीर को बदले बिना, अपने कपड़े बदल सकते हैं।
- वह मुख्य बिंदु # 2 है। यदि आप अपनी शर्ट बदलते हैं, तो आपको अपने शरीर को बदलने के लिए मजबूर नहीं किया जाता है - जब आप ऐसा कर सकते हैं, तो आपके पास ढीले युग्मन हैं। जब आप ऐसा नहीं कर सकते, तो आपके पास टाइट कपलिंग है।
संक्षेप में यही मूल अवधारणा है।
यह सब क्यों महत्वपूर्ण है?
यह महत्वपूर्ण है क्योंकि सॉफ्टवेयर हर समय बदलता है। सामान्यतया आप अपना कोड बदले बिना आसानी से अपने कोड को संशोधित करने में सक्षम होना चाहते हैं। मुझे पता है कि एक ऑक्सीमोरोन की तरह लगता है, लेकिन कृपया मेरे साथ सहन करें।
जब कोडिंग में युग्मन के व्यावहारिक उदाहरण
CSV / JSON / DB उदाहरण: यदि कोई JSON आदि के बजाय CSV फ़ाइल में अपना आउटपुट चाहता है, या यदि आप MySQL से PostGreSQL में स्विच करना चाहते हैं, तो आपको अपने कोड में उन बदलावों को आसानी से करने में सक्षम होना चाहिए, बिना फिर से लिखे। पूरी कक्षा आदि। दूसरे शब्दों में, आप एक विशिष्ट डेटाबेस कार्यान्वयन (उदाहरण के लिए मैसकल) या किसी विशेष आउटपुट (जैसे CSV फ़ाइलों) के साथ अपने एप्लिकेशन को कसकर जोड़ना नहीं चाहते हैं। क्योंकि, जैसा कि सॉफ्टवेयर में अपरिहार्य है, परिवर्तन आएंगे। जब वे आते हैं, तो यह बहुत आसान है अगर आपके कोड के कुछ हिस्सों को शिथिल रूप से युग्मित किया जाए।
कार पार्ट्स का उदाहरण: यदि कोई अपनी कार को काले रंग में चाहता है , तो आपको ऐसा करने के लिए पूरी कार को फिर से डिज़ाइन नहीं करना चाहिए। एक कार और उसके स्पेयर पार्ट्स एक शिथिल युग्मित वास्तुकला का एक आदर्श उदाहरण होंगे। यदि आप अपने इंजन को एक बेहतर के साथ बदलना चाहते हैं, तो आपको बहुत अधिक प्रयास के बिना बस अपने इंजन को निकालने में सक्षम होना चाहिए और इसे बेहतर के लिए स्वैप करना चाहिए। यदि आपकी कार केवल रोल्स रॉयस 1234 इंजन और कोई अन्य इंजन के साथ काम करती है - तो आपकी कार को कसकर उस इंजन (रोल्स रॉयस 1234) से जोड़ा जाएगा। बेहतर होगा कि आप अपनी कार का डिज़ाइन बदल दें ताकि वह किसी के साथ भी काम करेइंजन, इतना है कि यह घटकों के साथ थोड़ा अधिक युग्मित है। और भी बेहतर होगा अगर आपकी कार बिना इंजन की जरूरत के काम कर सके! युग्मन की कुछ मात्रा होने वाली है, लेकिन आपको इसे जितना हो सके कम से कम करने के लिए काम करना चाहिए। क्यों? क्योंकि जब आवश्यकताएं बदल जाती हैं, तो हमें अभी भी अच्छी गुणवत्ता वाले सॉफ़्टवेयर देने में सक्षम होना चाहिए, बहुत जल्दी और हम ढीले युग्मन द्वारा उस लक्ष्य में सहायता कर रहे हैं।
सारांश
संक्षेप में, ढीली युग्मन कोड को बदलने में आसान बनाता है। ऊपर दिए गए उत्तर कुछ कोड प्रदान करते हैं जो इस बिंदु पर पढ़ने लायक है।
बहुरूपता और ठोस सिद्धांत
पुन :: @TimoHuovinen टिप्पणी - ढीली युग्मन की अवधारणा बहुरूपता की अवधारणाओं के साथ हाथ से हाथ जाती है। यदि आप शर्ट / कार के पुर्ज़ों के मूल सादृश्य को समझ लेते हैं, तो आप बहुरूपता का बोध करने के लिए तैयार हो जाएंगे। इस बिंदु पर सबसे अच्छा तरीका है, इस धागे पर अन्य उत्तरों में मेरे अनुमान सहयोगियों द्वारा प्रदान किए गए कोड नमूने को पढ़ना है। अगर मैं कहता हूं कि आप बहुत अधिक जानकारी के साथ अतिभारित हो सकते हैं।
ऑब्जेक्ट ओरिएंटेड डिज़ाइन में, युग्मन की मात्रा यह बताती है कि एक वर्ग का डिज़ाइन दूसरे वर्ग के डिज़ाइन पर कितना निर्भर करता है। दूसरे शब्दों में, कक्षा A में कक्षा B में बल संबंधी परिवर्तन कितनी बार होते हैं? तंग युग्मन का अर्थ है दो वर्ग अक्सर एक साथ बदलते हैं, ढीले युग्मन का मतलब है कि वे ज्यादातर स्वतंत्र हैं। सामान्य तौर पर, ढीली युग्मन की सिफारिश की जाती है क्योंकि यह परीक्षण और बनाए रखना आसान है।
आप पा सकते हैं मार्टिन Fowler (पीडीएफ) द्वारा इस पत्र उपयोगी।
सामान्य तौर पर टाइट कपलिंग ज्यादातर समय में खराब होती है, क्योंकि यह कोड के लचीलेपन और पुन: प्रयोज्य को कम कर देता है, यह परिवर्तनों को और अधिक कठिन बना देता है, यह परीक्षण क्षमता आदि को बाधित करता है।
कसकर युग्मित वस्तु एक ऐसी वस्तु है जो एक दूसरे के बारे में काफी कुछ जानना चाहती है और आमतौर पर एक दूसरे के इंटरफेस पर अत्यधिक निर्भर होती है। एक ऑब्जेक्ट को कसकर युग्मित एप्लिकेशन में बदलने से अक्सर कई अन्य वस्तुओं में बदलाव की आवश्यकता होती है, छोटे अनुप्रयोग में हम आसानी से परिवर्तनों की पहचान कर सकते हैं और कुछ भी याद करने की कम संभावना है। लेकिन बड़े अनुप्रयोगों में ये अंतर-निर्भरताएं हमेशा हर प्रोग्रामर द्वारा ज्ञात नहीं होती हैं या मौका चूकने के लिए होता है। लेकिन शिथिल युग्मित वस्तुओं का प्रत्येक सेट दूसरों पर निर्भर नहीं है।
संक्षेप में हम कह सकते हैं, ढीली युग्मन एक डिज़ाइन लक्ष्य है जो सिस्टम के घटकों के बीच अन्योन्याश्रितताओं को कम करने का प्रयास करता है और साथ ही जोखिम को कम करने के लक्ष्य के साथ एक घटक में किसी अन्य घटक में बदलाव की आवश्यकता होगी। ढीली युग्मन प्रणाली के लचीलेपन को बढ़ाने, इसे और अधिक बनाए रखने और पूरे ढांचे को और अधिक 'स्थिर' बनाने के उद्देश्य से एक बहुत अधिक सामान्य अवधारणा है।
युग्मन प्रत्यक्ष ज्ञान की डिग्री को संदर्भित करता है जो एक तत्व दूसरे का है। हम कह सकते हैं जैसे: A और B, केवल B तभी अपना व्यवहार बदलते हैं जब A अपना व्यवहार बदलता है। एक शिथिल युग्मित प्रणाली को आसानी से निश्चित तत्वों में विभाजित किया जा सकता है।
जब दो वस्तुओं को शिथिल रूप से जोड़ा जाता है, तो वे परस्पर क्रिया कर सकते हैं लेकिन एक दूसरे के बारे में बहुत कम जानकारी रखते हैं।
ढीले कपल डिज़ाइन हमें लचीले ओओ सिस्टम बनाने की अनुमति देते हैं जो परिवर्तन को संभाल सकते हैं।
ऑब्जर्वर डिज़ाइन पैटर्न कक्षाओं को शिथिल बनाने के लिए एक अच्छा उदाहरण है, आप विकिपीडिया में इस पर एक नज़र डाल सकते हैं ।
युग्मन पर मेरे ब्लॉग पोस्ट से एक उद्धरण :
टाइट कपलिंग क्या है : -
जैसा कि ऊपर दी गई परिभाषा में एक कसकर युग्मित वस्तु एक वस्तु है जिसे अन्य वस्तुओं के बारे में जानने की आवश्यकता होती है और आमतौर पर एक दूसरे के इंटरफेस पर अत्यधिक निर्भर होते हैं।
जब हम किसी वस्तु को कसकर युग्मित अनुप्रयोग में बदलते हैं तो अक्सर उसे कई अन्य वस्तुओं में परिवर्तन की आवश्यकता होती है। एक छोटे से आवेदन में कोई समस्या नहीं है हम आसानी से बदलाव की पहचान कर सकते हैं। लेकिन बड़े अनुप्रयोगों के मामले में ये अंतर-निर्भरताएं हमेशा हर उपभोक्ता या अन्य डेवलपर्स द्वारा नहीं जानी जाती हैं या भविष्य में बदलाव की संभावना है।
चलो तंग युग्मन को समझने के लिए खरीदारी कार्ट डेमो कोड लेते हैं:
namespace DNSLooseCoupling
{
public class ShoppingCart
{
public float Price;
public int Quantity;
public float GetRowItemTotal()
{
return Price * Quantity;
}
}
public class ShoppingCartContents
{
public ShoppingCart[] items;
public float GetCartItemsTotal()
{
float cartTotal = 0;
foreach (ShoppingCart item in items)
{
cartTotal += item.GetRowItemTotal();
}
return cartTotal;
}
}
public class Order
{
private ShoppingCartContents cart;
private float salesTax;
public Order(ShoppingCartContents cart, float salesTax)
{
this.cart = cart;
this.salesTax = salesTax;
}
public float OrderTotal()
{
return cart.GetCartItemsTotal() * (2.0f + salesTax);
}
}
}
उपरोक्त उदाहरण के साथ समस्याएं
टाइट कपलिंग कुछ मुश्किलें पैदा करता है।
यहां, OrderTotal()कार्ट की वर्तमान वस्तुओं के लिए तरीके हमें पूरी राशि दे रहे हैं। यदि हम इस कार्ट सिस्टम में छूट सुविधाओं को जोड़ना चाहते हैं। उपरोक्त कोड में करना बहुत कठिन है क्योंकि हमें हर वर्ग में परिवर्तन करना है क्योंकि यह बहुत कसकर युग्मित है।
ढीली युग्मन का मतलब है कि दो घटकों के बीच निर्भरता की डिग्री बहुत कम है।
उदाहरण: जीएसएम सिम
तंग युग्मन का मतलब है कि दो घटकों के बीच निर्भरता की डिग्री बहुत अधिक है।
उदाहरण: सीडीएमए मोबाइल
जिस तरह से मैं समझता हूं कि यह है, कसकर युग्मित वास्तुकला शिथिल युग्मित वास्तुकला की तुलना में परिवर्तन के लिए बहुत अधिक लचीलापन प्रदान नहीं करता है।
लेकिन शिथिल युग्मित आर्किटेक्चर, संदेश प्रारूप या ऑपरेटिंग प्लेटफ़ॉर्म के मामले में या व्यापार तर्क को रद्द करने से दूसरे छोर पर प्रभाव नहीं पड़ता है। यदि सिस्टम को एक सुधार के लिए ले जाया जाता है, तो निश्चित रूप से दूसरा छोर कुछ समय के लिए सेवा तक नहीं पहुंच पाएगा, लेकिन इसके अलावा, अपरिवर्तित अंत संदेश विनिमय को फिर से शुरू कर सकता है क्योंकि यह सुधार से पहले था।
टाइट कपलिंग का मतलब है कि एक वर्ग दूसरे वर्ग पर निर्भर है।
लूज कपलिंग का मतलब है कि क्लास के बजाय एक क्लास इंटरफेस पर निर्भर है।
में तंग युग्मन , वहाँ हार्ड-कोडेड निर्भरता तरीकों में घोषित कर रहे हैं।
में ढीला संयोजन , हम बजाय हार्ड-कोडेड की कार्यावधि में बाह्य निर्भरता से गुजरना होगा। (ढीली जोड़ी प्रणाली वर्ग के साथ कम निर्भरता के लिए इंटरफ़ेस का उपयोग करती है।)
उदाहरण के लिए, हमारे पास एक प्रणाली है जो दो या अधिक तरीकों से आउटपुट भेज सकती है जैसे कि JSON आउटपुट, CSV आउटपुट इत्यादि।
टाइट कपल
public interface OutputGenerator {
public void generateOutput();
}
public class CSVOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("CSV Output Generator");
}
}
public class JSONOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("JSON Output Generator");
}
}
// In Other Code, we write Output Generator like...
public class Class1 {
public void generateOutput() {
// Here Output will be in CSV-Format, because of hard-coded code.
// This method tightly coupled with CSVOutputGenerator class, if we want another Output, we must change this method.
// Any method, that calls Class1's generateOutput will return CSVOutput, because Class1 is tight couple with CSVOutputGenerator.
OutputGenerator outputGenerator = new CSVOutputGenerator();
output.generateOutput();
}
}ऊपर दिए गए उदाहरण में, यदि हम JSON में आउटपुट बदलना चाहते हैं, तो हमें पूरे कोड को खोजने और बदलने की आवश्यकता है, क्योंकि Class1 को CSVOutputGenerator वर्ग के साथ कसकर जोड़ा गया है।
ढीले कपल
public interface OutputGenerator {
public void generateOutput();
}
public class CSVOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("CSV Output Generator");
}
}
public class JSONOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("JSON Output Generator");
}
}
// In Other Code, we write Output Generator like...
public class Class1 {
public void generateOutput(OutputGenerator outputGenerator) {
// if you want to write JSON, pass object of JSONOutputGenerator (Dependency will be passed externally to this method)
// if you want to write CSV, pass object of CSVOutputGenerator (Dependency will be passed externally to this method)
// Due to loose couple with class, we don't need to change code of Class1, because Class1 is loose coupled with CSVOutputGenerator or JSONOutputGenerator class
// Any method, that calls Class1's generateOutput will desired output, because Class1 does not tight couple with CSVOutputGenerator or JSONOutputGenerator class
OutputGenerator outputGenerator = outputGenerator;
output.generateOutput();
}
}ऐसे कुछ उपकरण हैं जो उनके पुस्तकालय के माध्यम से निर्भरता इंजेक्शन प्रदान करते हैं, उदाहरण के लिए .net में हमारे पास निनेज़ लाइब्रेरी है ।
यदि आप जावा में आगे जा रहे हैं तो वसंत इस क्षमताओं को प्रदान करता है।
अपने कोड में Interfaces की शुरुआत करके ढीली कपल ऑब्जेक्ट बनाया जा सकता है, जो कि ये स्रोत करते हैं।
अपने कोड में कहें कि आप लिख रहे हैं
Myclass m = new Myclass();
अब आपकी विधि में यह कथन कहता है कि आप myclassइस पर निर्भर हैं इसे कसकर युग्मित कहा जाता है। अब आप कुछ कंस्ट्रक्टर इंजेक्शन, या प्रॉपर्टी इंजेक्शन और इंस्टेंटिंग ऑब्जेक्ट प्रदान करते हैं तो यह शिथिल रूप से युग्मित हो जाएगा।
उपमाओं का उपयोग करते हुए यहां बहुत अच्छे उत्तर हैं, लेकिन काम पर एक मित्र ने मुझे एक उदाहरण दिया जो मुझे यहां वर्णित सभी से अधिक पसंद आया ... आंखें और चश्मा!
कसा हुआ संयोजन
तंग युग्मन आंखों होगा। अगर मैं अपनी दृष्टि को ठीक करना चाहता हूं, तो नेत्र प्रत्यारोपण कराने के लिए मैं बहुत महंगा हूं और उचित मात्रा में जोखिम रखता हूं। लेकिन क्या होगा अगर डिजाइनर (मानव जाति होने के नाते) ने एक बेहतर तरीका पाया। एक ऐसी सुविधा जोड़ें जो शिथिल रूप से शरीर से जुड़ी हो ताकि इसे आसानी से बदला जा सके! (हां .. चश्मा)
ढीला युग्मन
मैं अपनी अंतर्निहित दृष्टि को तोड़े बिना अपने चश्मे को आसानी से बदल सकता हूं। मैं चश्मा उतार सकता हूं और मेरी दृष्टि यह होगी कि यह पहले कैसे था (बेहतर या बदतर नहीं)। चश्मे के विभिन्न जोड़े का उपयोग करके परिवर्तन होता है कि कैसे हम दुनिया को अपनी आंखों से थोड़ा जोखिम और आसान रखरखाव के साथ देखते हैं।
सारांश
तो अगली बार जब कोई आपसे पूछता है "कौन परवाह करता है कि मेरा कोड कसकर-युग्मित है?" उत्तर सभी को बदलने के प्रयास, बनाए रखने के प्रयास और परिवर्तन के जोखिम के बारे में है।
तो यह C # में कैसे किया जाता है? इंटरफेस और निर्भरता इंजेक्शन!
संपादित करें
डेकोरेटर पैटर्न का यह एक अच्छा उदाहरण है, जहां आंखें वह वर्ग है जिसे हम इंटरफ़ेस आवश्यकताओं को पूरा करके सजा रहे हैं, लेकिन विभिन्न कार्यक्षमता दे रहे हैं (जैसे धूप का चश्मा, चश्मा पढ़ना, ज्वैलर्स के लिए चश्मा बढ़ाना आदि)
ढीली युग्मन है और पुरानी शैली के हार्डकोडेड निर्भरता और संबंधित मुद्दों जैसे कि अक्सर पुनर्संयोजन और जब कुछ भी परिवर्तन और पुन: उपयोग के लिए समस्याएँ होती हैं, का जवाब। यह घटकों में कार्यकर्ता तर्क को लागू करने और वहां समाधान के विशिष्ट तार अप कोड से बचने पर जोर देता है।
ढीली युग्मन वह निर्भरता देने की प्रक्रिया है जिसे आपकी कक्षा को अप्रत्यक्ष रूप से निर्भरता की सभी जानकारी प्रदान करने की आवश्यकता है (अर्थात इंटरफ़ेस से) यदि आप सीधे आश्रितता में देते हैं तो यह अच्छा तरीका है जो कोडिंग का अच्छा तरीका नहीं है।
यह उन वर्गों पर निर्भरता दर के बारे में है जो बहुत कम युग्मित हैं और बहुत अधिक कसकर युग्मित हैं। सेवा अभिविन्यास वास्तुकला में स्पष्ट होने के लिए , सेवाओं को अखंड रूप से एक-दूसरे के खिलाफ युग्मित किया जाता है, जो एक दूसरे पर निर्भरता के उद्देश्य से वर्ग हैं।
यदि किसी वस्तु का निर्माण / अस्तित्व किसी अन्य वस्तु पर निर्भर करता है, जिसे सिलवाया नहीं जा सकता है, तो इसकी टाइट कपलिंग। और, अगर निर्भरता के अनुरूप हो सकता है, तो इसकी ढीली युग्मन। जावा में एक उदाहरण पर विचार करें:
class Car {
private Engine engine = new Engine( "X_COMPANY" ); // this car is being created with "X_COMPANY" engine
// Other parts
public Car() {
// implemenation
}
}
Carकक्षा का ग्राहक केवल "X_COMPANY" इंजन के साथ एक बना सकता है।
इस युग्मन को बदलने की क्षमता के साथ तोड़ने पर विचार करें:
class Car {
private Engine engine;
// Other members
public Car( Engine engine ) { // this car can be created with any Engine type
this.engine = engine;
}
}
अब, एक Car"X_COMPANY" के इंजन पर निर्भर नहीं है क्योंकि यह प्रकारों के साथ बनाया जा सकता है।
एक जावा विशिष्ट नोट: सिर्फ डी-कपलिंग खातिर जावा इंटरफेस का उपयोग करना एक उचित इच्छा दृष्टिकोण नहीं है। जावा में, एक इंटरफ़ेस का एक उद्देश्य है - एक अनुबंध के रूप में कार्य करना जो आंतरिक रूप से डी-कपलिंग व्यवहार / लाभ प्रदान करता है।
बिल रोसमस की टिप्पणी को स्वीकार किए गए उत्तर में अच्छी व्याख्या है।
तंग युग्मन का अर्थ है कक्षाएं और वस्तुएं एक दूसरे पर निर्भर हैं। सामान्य तौर पर, तंग युग्मन आमतौर पर अच्छा नहीं होता है क्योंकि यह कोड के लचीलेपन और पुन: प्रयोज्य को कम करता है जबकि लूज़ युग्मन का अर्थ है एक वर्ग की निर्भरता को कम करना जो सीधे विभिन्न वर्ग का उपयोग करता है।
तंग युग्मन कसकर युग्मित वस्तु एक ऐसी वस्तु है जिसे अन्य वस्तुओं के बारे में जानने की आवश्यकता होती है और आमतौर पर एक दूसरे के इंटरफेस पर अत्यधिक निर्भर होती है। एक वस्तु को कसकर युग्मित अनुप्रयोग में बदलने से अक्सर कई अन्य वस्तुओं में परिवर्तन की आवश्यकता होती है। छोटे अनुप्रयोगों में, हम आसानी से परिवर्तनों की पहचान कर सकते हैं और कुछ भी याद करने की संभावना कम है। लेकिन बड़े अनुप्रयोगों में, ये अंतर-निर्भरताएं हमेशा हर प्रोग्रामर द्वारा ज्ञात नहीं होती हैं और परिवर्तन को देखने का एक मौका होता है। उदाहरण:
class A {
public int a = 0;
public int getA() {
System.out.println("getA() method");
return a;
}
public void setA(int aa) {
if(!(aa > 10))
a = aa;
}
}
public class B {
public static void main(String[] args) {
A aObject = new A();
aObject.a = 100; // Not suppose to happen as defined by class A, this causes tight coupling.
System.out.println("aObject.a value is: " + aObject.a);
}
}
In the above example, the code that is defined by this kind of implementation uses tight coupling and is very bad since class B knows about the detail of class A, if class A changes the variable 'a' to private then class B breaks, also class A's implementation states that variable 'a' should not be more than 10 but as we can see there is no way to enforce such a rule as we can go directly to the variable and change its state to whatever value we decide.
Output
aObject.a value is: 100
Loose Coupling
Loose coupling is a design goal to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component.
Loose coupling is a much more generic concept intended to increase the flexibility of the system, make it more maintainable and makes the entire framework more stable.
Example:
class A {
private int a = 0;
public int getA() {
System.out.println("getA() method");
return a;
}
public void setA(int aa) {
if(!(aa > 10))
a = aa;
}
}
public class B {
public static void main(String[] args) {
A aObject = new A();
aObject.setA(100); // No way to set 'a' to such value as this method call will
// fail due to its enforced rule.
System.out.println("aObject value is: " + aObject.getA());
}
}
उपरोक्त उदाहरण में, इस तरह के कार्यान्वयन से परिभाषित कोड ढीले युग्मन का उपयोग करता है और इसकी सिफारिश की जाती है क्योंकि कक्षा बी को अपना राज्य प्राप्त करने के लिए कक्षा ए से गुजरना पड़ता है जहां नियम लागू होते हैं। यदि क्लास ए को आंतरिक रूप से बदल दिया जाता है, तो क्लास बी नहीं टूटेगा क्योंकि यह संचार के एक तरीके के रूप में केवल क्लास ए का उपयोग करता है।
Output
getA() method
aObject value is: 0