'युग्मन में निम्न और सामंजस्य में उच्च' का क्या अर्थ है


151

मुझे कथन को समझने में समस्या है low in coupling and high in cohesion। मैंने इस बारे में बहुत कुछ जाना और पढ़ा है, लेकिन अभी भी इसे समझना मुश्किल है।

जो मैं समझता हूं उसका High cohesionमतलब है, हमारे पास ऐसी कक्षाएं होनी चाहिए जो किसी विशेष कार्य को करने के लिए विशिष्ट हों। आशा है कि यह सही है? क्रेडिट कार्ड सत्यापन वर्ग की तरह, जो केवल क्रेडिट कार्ड को मान्य करने के लिए विशिष्ट है।

और अभी भी समझ में नहीं आता है कि क्या कम युग्मन का मतलब है?


4
अधिक विस्तृत विवरण के लिए, आप इस पोस्ट से जवाब पसंद कर सकते हैं Cohesion & Coupling
Infinity

यह उत्तर निश्चित रूप से बेहतर है और संक्षिप्त है तो यहाँ दिए गए हैं।
लोकेश

वास्तव में, यह उन लोगों की नकल है। इन्फिनिटी द्वारा उत्तर केवल गैर-डुप्लिकेट है जिसका उल्लेख यहां अब तक नहीं किया गया है।
cellepo

जवाबों:


232

मेरा मानना ​​है कि यह है:

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

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

पूरी तस्वीर की कल्पना करना मददगार होगा:

यहाँ छवि विवरण दर्ज करें

स्क्रीनशॉट Coursera से लिया गया था ।


20
हमारे प्रोफेसर कहते हैं, "उच्च सामंजस्य यह सुनिश्चित करने के बारे में है कि मॉड्यूल कई चीजें नहीं करता है, इसका मतलब केवल एक विशेष चीज करना है"।
लोकेश

2
मेरा मानना ​​है कि यह अधिक पसंद है "यह सुनिश्चित करना कि एक मॉड्यूल एक चीज करता है, न कि कई मॉड्यूल एक ही काम करते हैं", इसके द्वारा आप यह सुनिश्चित कर सकते हैं कि केवल एक मॉड्यूल व्यवहार को निर्दिष्ट करता है, इसलिए किसी चीज के लिए समग्र व्यवहार सामंजस्यपूर्ण है।
sschrass

5
@ लोकेश मुझे लगता है कि आपकी टिप्पणी से बातें घटती हैं। आपका प्रोफेसर "एकल जिम्मेदारी सिद्धांत" के साथ उच्च सामंजस्य को भ्रमित कर रहा है। उच्च सामंजस्य का मतलब समान और संबंधित चीजों को एक साथ रखना है। आप एक वस्तु या एक सेवा में उच्च सामंजस्य रख सकते हैं जो कई कार्यों से बना है।
मैक्स होजेस

17
उस आरेख का शाब्दिक अर्थ है कुछ भी नहीं।
लियाम

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

41

सॉफ्टवेयर इंजीनियरिंग में, वास्तविक जीवन में सामंजस्य यह है कि एक पूरे (हमारे मामले में एक वर्ग कहते हैं) तत्वों को कितना कहा जा सकता है कि वे वास्तव में एक साथ हैं। इस प्रकार, यह एक माप है कि सॉफ्टवेयर मॉड्यूल के स्रोत कोड द्वारा व्यक्त कार्यक्षमता का प्रत्येक टुकड़ा कितनी दृढ़ता से संबंधित है।

OO के संदर्भ में सामंजस्य देखने का एक तरीका यह है कि यदि कक्षा में विधियाँ किसी भी निजी विशेषता का उपयोग कर रही हैं।

अब चर्चा इससे बड़ी है लेकिन उच्च सामंजस्य (या सामंजस्य का सबसे अच्छा प्रकार - कार्यात्मक सामंजस्य) है जब एक मॉड्यूल के कुछ हिस्सों को समूहीकृत किया जाता है क्योंकि वे सभी मॉड्यूल के एकल-परिभाषित कार्य में योगदान करते हैं।

सरल शब्दों में युग्मन , एक घटक (फिर से, एक वर्ग की कल्पना करें, हालांकि जरूरी नहीं) एक दूसरे के आंतरिक कामकाज या आंतरिक तत्वों के बारे में जानता है, अर्थात इसके दूसरे घटक का कितना ज्ञान है।

ढीली युग्मन प्रणाली या नेटवर्क में घटकों को आपस में जोड़ने का एक तरीका है ताकि वे घटक, एक दूसरे पर कम से कम व्यावहारिक रूप से संभव हो…

मैंने इस बारे में एक ब्लॉग पोस्ट लिखा था । यह इस सब पर बहुत विस्तार से चर्चा करता है, उदाहरण आदि के साथ यह भी बताता है कि आपको इन सिद्धांतों का पालन क्यों करना चाहिए।


26

सॉफ्टवेयर डिजाइन में उच्च सामंजस्य का मतलब है कि कक्षा को एक काम करना चाहिए और एक चीज़ को बहुत अच्छी तरह से करना चाहिए। उच्च सामंजस्य एकल जिम्मेदारी सिद्धांत से निकटता से संबंधित है ।

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

उच्च सामंजस्य और कम युग्मन हमें बेहतर डिज़ाइन किए गए कोड देते हैं जो बनाए रखना आसान है।


आप डिपेंडेंसी इंजेक्शन से चूक गए। यह सुनिश्चित करने के लिए कम युग्मन से संबंधित है कि किसी वर्ग की कम से कम / कोई निर्भरता नहीं है।
BugHunterUK

16

संक्षिप्त और स्पष्ट उत्तर

  • उच्च सामंजस्य : एक वर्ग / मॉड्यूल के भीतर तत्वों को कार्यात्मक रूप से एक साथ होना चाहिए और एक विशेष कार्य करना चाहिए।
  • ढीली युग्मन : विभिन्न वर्गों / मॉड्यूलों के बीच न्यूनतम निर्भरता होनी चाहिए।

9

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

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

उम्मीद है की वो मदद करदे।


5

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


1
उच्च सामंजस्य के रूप में ही नहीं है?
user1315906

4

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


> क्या एक ऐप दूसरे पर रिप्लाई करता है? । । अच्छा हाँ, कुछ करते हैं। कई ऐप कैमरा ऐप का इस्तेमाल करते हैं, वर्कआउट ऐप द्वारा हार्ट और वर्कआउट डेटा को हेल्थ और एक्टिविटीज़ को फीड किया जाता है। मैं एक ऐप से कई अन्य लोगों के लिए एक स्निपेट साझा कर सकता हूं। मेरा अलार्म ऐप समय जानता है और म्यूजिक ऐप से ट्रैक प्ले करता है ...
मैक्स होजेस

@MaxHodges उस चीज़ (कम सामंजस्य और उच्च युग्मन) को अवमूल्यित करता है और इसे कम से कम संभव तक कम से कम किया जाना चाहिए। कुछ मामलों में, जैसा कि आपने उल्लेख किया है। इसे पूरी तरह से हटाया नहीं जा सकता।
एम। हबीब

2

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

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


2

सामंजस्य - एक दूसरे के साथ सब कुछ कितनी बारीकी से संबंधित है।
युग्मन - कैसे सब कुछ एक दूसरे से जुड़ा हुआ है।

एक उदाहरण लेते हैं - हम एक स्व-ड्राइविंग कार डिजाइन करना चाहते हैं।

(1) हमें ठीक से चलने के लिए मोटर की आवश्यकता होती है।

(२) हमें कार को स्वयं चलाने की आवश्यकता है।

(1) मोटर शुरू करने और इसे चलाने में काम करने वाले सभी वर्ग और फ़ंक्शंस एक साथ काम करते हैं, लेकिन कार चलाने में मदद नहीं करते हैं। इसलिए हम उन कक्षाओं को इंजन कंट्रोलर के पीछे रखते हैं।

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

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

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


1

कम युग्मन और उच्च सामंजस्य एक अनुशंसित घटना है।

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


1

एक उदाहरण सहायक हो सकता है। एक प्रणाली की कल्पना करें जो डेटा उत्पन्न करती है और इसे डेटा स्टोर में डालती है, या तो डिस्क या डेटाबेस पर एक फ़ाइल।

डेटा उत्पादन कोड से डेटा स्टोर कोड को अलग करके उच्च सामंजस्य प्राप्त किया जा सकता है। (और वास्तव में डेटाबेस स्टोरेज से डिस्क स्टोरेज को अलग करना)।

कम युग्मन यह सुनिश्चित करके प्राप्त किया जा सकता है कि डेटा उत्पादन में डेटा स्टोर का कोई अनावश्यक ज्ञान नहीं है (जैसे फ़ाइल नाम या डीबी कनेक्शन के बारे में डेटा स्टोर से नहीं पूछता है)।


1

यहाँ एक सार, ग्राफ प्रमेय कोण का एक सा उत्तर दिया गया है:

आइए केवल राज्य की वस्तुओं के बीच (निर्देशित) निर्भरता ग्राफ को देखकर समस्या को सरल करें।

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

1 सीमित मामला : एक क्लस्टर रेखांकन

एक क्लस्टर ग्राफ एक उच्च सामंजस्य और कम युग्मन (क्लस्टर आकार का एक सेट) निर्भरता ग्राफ का सबसे सही एहसास है।

क्लस्टर के बीच निर्भरता अधिकतम (पूरी तरह से जुड़ी हुई) है, और अंतर क्लस्टर निर्भरता न्यूनतम (शून्य) है।

यह सीमित मामलों में से एक में एक अमूर्त चित्रण है

दूसरा सीमित मामला पूरी तरह से जुड़ा हुआ ग्राफ है, जहां सब कुछ सब कुछ पर निर्भर करता है।

वास्तविकता बीच में कहीं है, क्लस्टर ग्राफ के करीब, मेरी विनम्र समझ में बेहतर है।

दूसरे दृष्टिकोण से : जब एक निर्देशित निर्भरता ग्राफ को देखते हुए, आदर्श रूप से यह चक्रीय होना चाहिए, यदि नहीं तो चक्र सबसे छोटे समूहों / घटकों का निर्माण करते हैं।

एक कदम ऊपर / नीचे पदानुक्रम एक सॉफ्टवेयर में ढीले युग्मन, तंग सामंजस्य के "एक उदाहरण" से मेल खाता है लेकिन इस ढीले युग्मन / तंग सामंजस्य सिद्धांत को एक एसाइक्लिक निर्देशित ग्राफ की अलग-अलग गहराई पर पुनरावृत्ति घटना के रूप में देखना संभव है (या पर) इसके फैले हुए वृक्षों में से एक)।

एक पदानुक्रम में सिस्टम का ऐसा अपघटन घातीय जटिलता (प्रत्येक क्लस्टर में 10 तत्व हैं) को हरा करने में मदद करता है। फिर 6 परतों पर यह पहले से ही 1 मिलियन ऑब्जेक्ट है:

10 क्लस्टर 1 सुपरक्लस्टर, 10 सुपरक्लस्टर और 1 हाइपरक्लस्टर और इसी तरह के रूप में ... तंग सामंजस्य, ढीली युग्मन की अवधारणा के बिना, इस तरह के पदानुक्रमित वास्तुकला संभव नहीं होगा।

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


0

मुझे लगता है कि आपके पास बहुत सारी परिभाषाएँ हैं, लेकिन यदि आपके पास अभी भी संदेह है या मामले में आप प्रोग्रामिंग में नए हैं और इस बारे में गहराई से जाना चाहते हैं, तो मैं आपको इस वीडियो को देखने का सुझाव दूंगा, https://youtu.be/HpJTGW9wwX0 यह सिर्फ बहुरूपता के बारे में अधिक जानकारी प्राप्त करने के लिए संदर्भ है ... आशा है कि आप इस के साथ बेहतर समझ प्राप्त करेंगे


0

लो कपलिंग: - इसे बहुत सरल रखेंगे। यदि आप अपना मॉड्यूल बदलते हैं तो यह अन्य मॉड्यूल को कैसे प्रभावित करता है।

उदाहरण: - यदि आपकी सेवा एपीआई को जार के रूप में उजागर किया जाता है, तो विधि हस्ताक्षर में कोई भी परिवर्तन एपीआई (उच्च / तंग युग्मन) को तोड़ देगा।

यदि आपका मॉड्यूल और अन्य मॉड्यूल async संदेशों के माध्यम से संवाद करते हैं। जब तक आप संदेश प्राप्त करते हैं, तब तक आपकी विधि परिवर्तन हस्ताक्षर आपके मॉड्यूल (कम युग्मन) के लिए स्थानीय होगा।

ऑफ-कोर्स यदि संदेश प्रारूप में परिवर्तन होता है, तो कॉलिंग क्लाइंट को कुछ परिवर्तन करने की आवश्यकता होगी।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.