'उच्च सामंजस्य' का अर्थ क्या है?

Question

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

मैं कम युग्मन का अर्थ समझता हूं। इसका मतलब अलग-अलग घटकों के कोड को अलग-अलग रखना है, ताकि एक स्थान पर परिवर्तन दूसरे में कोड को न तोड़े।

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

उच्च सामंजस्य से क्या अभिप्राय है? क्या एक उदाहरण से इसके लाभों को समझने के लिए समझाया जा सकता है?

Comments

क्या

— gnat

क्या विकिपीडिया लेख आपके प्रश्न का पर्याप्त उत्तर नहीं देता है? en.wikipedia.org/wiki/Cohesion_(computer_science)

— इयॉन कैरोल

इस बारे में एक अच्छा लेख है: msdn.microsoft.com/en-us/magazine/cc947917.aspx

— NoChance

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

— Spoike

जब तक मैंने क्लीन कोड नहीं पढ़ा, मैं वास्तव में सामंजस्य को कभी नहीं समझ पाया। तुम भी।

— सेबेस्टियन रेडल

Answer 1

OO के संदर्भ में सामंजस्य को देखने का एक तरीका यह है कि क्या कक्षा में विधियाँ किसी भी निजी विशेषता का उपयोग कर रही हैं। LCOM4 (Lack of Cohesive Methods) जैसे मेट्रिक्स का उपयोग करते हुए, जैसा कि यहाँ इस उत्तर में gnat द्वारा बताया गया है , आप उन वर्गों की पहचान कर सकते हैं जिन्हें रिफैक्ट किया जा सकता है। जिस तरीके से आप रिफ्लेक्टर विधियों या कक्षाओं को अधिक सामंजस्यपूर्ण बनाना चाहते हैं, वह यह है कि यह दूसरों को इसका उपयोग करने के लिए कोड डिज़ाइन को सरल बनाता है । मुझ पर विश्वास करो; जब आप इन मुद्दों को ठीक करते हैं तो अधिकांश टेक लीड और रखरखाव प्रोग्रामर आपसे प्यार करेंगे।

कोड आधार में कम सामंजस्य की पहचान करने के लिए आप अपनी निर्माण प्रक्रिया में उपकरणों का उपयोग कर सकते हैं जैसे सोनार । कुछ बहुत ही सामान्य मामले हैं जो मैं सोच सकता हूं कि "सामंजस्य" में तरीके कहां कम हैं :

केस 1: विधि कक्षा से संबंधित नहीं है

निम्नलिखित उदाहरण पर विचार करें:

public class Food {
   private int _foodValue = 10;

   public void Eat() {
     _foodValue -= 1;
   }

   public void Replenish() {
     _foodValue += 1;
   }

   public void Discharge() {
     Console.WriteLine("Nnngghhh!");
   }
}

विधियों में से एक Discharge(), सामंजस्य का अभाव है क्योंकि यह कक्षा के किसी भी निजी सदस्य को नहीं छूता है। इस मामले में केवल एक निजी सदस्य है _foodValue:। यदि यह वर्ग के लोगों के साथ कुछ नहीं करता है, तो क्या यह वास्तव में वहां है? विधि को किसी अन्य वर्ग में स्थानांतरित किया जा सकता है जिसे उदाहरण के लिए नाम दिया जा सकता है FoodDischarger।

// Non-cohesive function extracted to another class, which can
// be potentially reused in other contexts
public FoodDischarger {
  public void Discharge() {
    Console.WriteLine("Nnngghhh!");
  }
}

आप इसे जावास्क्रिप्ट में कर रहे हैं, क्योंकि फ़ंक्शंस प्रथम श्रेणी के ऑब्जेक्ट हैं, डिस्चार्ज एक नि: शुल्क फ़ंक्शन हो सकता है:

function Food() {
    this._foodValue = 10;
}
Food.prototype.eat = function() {
    this._foodValue -= 1;
};
Food.prototype.replenish = function() {
    this._foodValue += 1;
};

// This
Food.prototype.discharge = function() {
    console.log('Nnngghhh!');
};
// can easily be refactored to:
var discharge = function() {
    console.log('Nnngghhh!');
};
// making it easily reusable without creating a class

केस 2: उपयोगिता वर्ग

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

public class Food {
    public int FoodValue { get; set; }
}

public static class FoodHelper {

    public static void EatFood(Food food) {
        food.FoodValue -= 1;
    }

    public static void ReplenishFood(Food food) {
        food.FoodValue += 1;
    }

}

यहां हम देख सकते हैं कि उपयोगिता वर्ग को वर्ग में एक संपत्ति तक पहुंचने की आवश्यकता है Food। उपयोगिता वर्ग के तरीकों में इस मामले में कोई सामंजस्य नहीं है क्योंकि इसे काम करने के लिए बाहरी संसाधनों की आवश्यकता होती है। इस मामले में, क्या वे जिस कक्षा में खुद के साथ काम कर रहे हैं (पहले मामले में बहुत पसंद करते हैं) करना बेहतर नहीं होगा?

केस 2 बी: यूटिलिटी क्लासेस में छिपा हुआ सामान

उपयोगिता वर्गों का एक और मामला है जहां अवास्तविक डोमेन ऑब्जेक्ट हैं। एक प्रोग्रामर के पास पहले घुटने के झटका की प्रतिक्रिया होती है जब प्रोग्रामिंग स्ट्रिंग हेरफेर इसके लिए एक उपयोगिता वर्ग लिखना है। आम स्ट्रिंग प्रतिनिधित्व के एक जोड़े को मान्य करने वाले यहाँ की तरह:

public static class StringUtils {

  public static bool ValidateZipCode(string zipcode) {
    // validation logic
  }

  public static bool ValidatePhoneNumber(string phoneNumber) {
    // validation logic
  }

}

यहाँ जो कुछ भी महसूस नहीं होता है वह यह है कि एक ज़िप कोड, एक फ़ोन नंबर, या कोई अन्य स्ट्रिंग रीसेन्टेशन एक वस्तु हो सकती है:

public class ZipCode {
    private string _zipCode;
    public bool Validates() {
      // validation logic for _zipCode
    }
}

public class PhoneNumber {
    private string _phoneNumber;
    public bool Validates() {
      // validation logic for _phoneNumber
    }
}

यह धारणा कि आपको "स्ट्रिंग्स को हैंडल नहीं करना चाहिए" इस ब्लॉगपोस्ट में विस्तृत रूप से @codemonkeyism द्वारा विस्तृत है , लेकिन सामंजस्य से निकटता से संबंधित है क्योंकि जिस तरह से प्रोग्रामर उपयोगिता कक्षाओं में तर्क डालकर तार का उपयोग करते हैं।

Comments

अब यदि केवल हम अपने ORMs को अपने कस्टम ज़िपकोड और PhoneNumber कक्षाओं को ठीक से संभालने के लिए प्राप्त कर सकते हैं: |

— पीट

+1 अच्छे उदाहरण। अंतिम बिंदु के लिए, sourcemaking.com/refactoring/primitive-obsession

— AlexFoxGill

@Pete आपका ORM यह संभाल लेंगे अगर आप अपने परिभाषित प्रकार (ज़िपकोड, PhoneNumber) को स्ट्रिंग से रूपांतरण ऑपरेटरों प्रदान करते हैं: msdn.microsoft.com/en-us/library/85w54y0a.aspx

— मार्कस

Answer 2

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

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

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

Answer 3

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

Comments

क्या यह केवल वस्तुओं की तुलना में उच्च स्तर पर भी लागू नहीं होता है? जैसे नाम स्थान में किसी कार्य से संबंधित कार्य / कार्य को समूहीकृत करना?

— टिजिन