युग्मन और सामंजस्य के बारे में वस्तु-उन्मुख प्रणालियों पर कानून का कानून कैसे लागू होता है? [बन्द है]


15

युग्मन और सामंजस्य के साथ ऑब्जेक्ट ऑफ़ ओरिएंटेड सिस्टम पर डेमेटर ऑफ़ लॉ कैसे लागू होता है?

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


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

जवाबों:


9

एमर्सन मैसिडो के अनुसार लॉ ऑफ डेमीटर निम्नलिखित कहता है:

  • प्रत्येक इकाई को केवल अन्य इकाइयों के बारे में सीमित ज्ञान होना चाहिए: केवल इकाइयां वर्तमान इकाई से संबंधित "बारीकी से"।
  • प्रत्येक इकाई को केवल अपने दोस्तों से बात करनी चाहिए; अजनबियों से बात न करें।
  • केवल अपने तात्कालिक दोस्तों से बात करें।

यह सीधे कम युग्मन के सिद्धांत से मेल खाता है क्योंकि इकाइयाँ (या वस्तुएं) ऊपर की तरह मानी जाती हैं:

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

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

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


8

युग्मन, सरलीकृत

जब कोई वस्तु किसी अन्य वस्तु की विधि, गुण आदि को कहती है, तो हम कहते हैं कि वस्तुएं युग्मित हैं। हम इसे युग्मन कहते हैं क्योंकि अब कैली अपने स्वयं के तरीके / प्रस्ताव के बारे में कुछ भी नहीं बदल सकता है । w.out कॉलर को तोड़ना ।

इस प्रकार, अधिक युग्मन - तरीके, सहारा। - कठिन है कि सभी कोड को तोड़ने के बिना कैली कोड को बदलना है जो इसका उपयोग करता है।

युग्मन पर विचार करना

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

अधिकांश ज्ञान पागल युग्मन का कारण बनता है

यहाँ हम एक है Employeeहै कि एक Personएक 'पता' है

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

सड़क प्राप्त करने के लिए मैं कॉल करना होगा: myEmployee.me.home.street। यह कम से कम ज्ञान के सिद्धांत के विपरीत 180 डिग्री है। मैं करने के लिए है पता है internals, समग्र संरचना, के बारे में Employee, Personहै, और Addressवर्गों।

यह दोषपूर्ण वर्ग डिजाइन मुझे उन सभी वर्गों के बारे में जानने के लिए मजबूर करता है और इस प्रकार myEmployee.me.home.streetमुझे (कॉलर ऑब्जेक्ट) 3 वर्गों से कम नहीं - केवल एक संपत्ति प्राप्त करने के लिए!

कम से कम ज्ञान दिन बचाता है

यदि मैं केवल Employeeकक्षा से बात करता हूं तो मैं प्रति से कम से कम ज्ञान सिद्धांत को लागू कर रहा हूं, और ऐसा करके हम स्वचालित रूप से केवल उस वर्ग के लिए युग्मन को सीमित करते हैं , और साथ ही साथ उस एक वर्ग को युग्मन को अलग करते हैं

Employeeवर्ग में सभी आवश्यक गुणों को जोड़कर हम युग्मन को ठीक करते हैं।

इस प्रकार

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

मुझे कॉल करने की अनुमति देता है: myEmployee.street-

  1. मैं केवल "जानता हूं" Employee
  2. मैं केवल युग्मित हूं Employee- चाहे इसकी संरचना कितनी भी जटिल क्यों न हो।

कम से कम सभी तरह के ज्ञान

हम से myEmployee decoupled Personऔर Addressऔर आदर्श रूप में हम जोड़कर कम से कम ज्ञान को लागू जारी रखना चाहिए के माध्यम से पारित करने के गुण ऐसा है कि Employeeकरने के लिए केवल वार्ता Personऔर Personकेवल करने के लिए वार्ताAddress


1

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

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


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

0

यह बहुत आसान है; A A B पर निर्भर करता है और B, C पर निर्भर करता है। Law Law of Laweter के बिना आप A में B और C दोनों का उपयोग कर सकते हैं, लेकिन इस कानून का पालन करने से, A केवल B पर निर्भर करता है, यह C पर निर्भर नहीं हो सकता।

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

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