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



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



यह लेख मुख्य रूप से PHP को संदर्भित करता है, लेकिन कुछ आरक्षणों के साथ, यह कई अन्य गतिशील भाषाओं के लिए भी उपयुक्त है जो अशुद्धियों को लागू करने के लिए एक या दूसरे तरीके की अनुमति देते हैं।







यह लेख किसी तरह से PHP में अशुद्धियों के कार्यान्वयन के बारे में इस लेख की एक तार्किक निरंतरता है। यदि आप रुचि रखते हैं, तो इसे पढ़ें। यदि नहीं, तो यहां प्रस्तुत सामग्री को समझने में कोई समस्या नहीं होगी।

कोड नमूने

पहले, चलो कोड का उपयोग करने वाले दो दृष्टिकोणों के बीच के अंतर को देखते हैं जो समान कार्य करता है।

अपवित्रता

class Aggregator { } class Mixin { public function doSomething() {} } Mixins::mix("Aggregator", "Mixin"); $a = new Aggregator (); $a->doSomething();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

प्रतिनिधिमंडल

 Class Aggregator {} class Mixin { public function doSomething() {} } class AggregatorMixed extends Aggregator { private $mixin; function __construct() { $mixin = new Mixin(); } public function doSomething() { $mixin->doSomething(); } } $a = new AggregatorMixed (); $a->doSomething();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

तकनीकी अंतर

तकनीकी दृष्टि से दो टुकड़ों में क्या अंतर है? वे वही कार्यक्षमता प्रदान करते हैं, जैसा कि आप देख सकते हैं।



1. अशुद्धता के तरीकों को नाम से गतिशील रूप से कहा जाता है, और प्रतिनिधिमंडल के मामले में, कोड निष्पादित करने से पहले कंपाइलर जांच कर सकता है।



डायनामिक कॉल्स कार्यक्रम में लचीलापन लाते हैं, जो संकलन समय पर किसी भी प्रकार की जाँच की लागत पर आता है। अशुद्धियों का उपयोग करने के मामले में, अतिरिक्त इकाई परीक्षण काम में आएंगे।



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



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



एक और छोटा परिणाम यह है कि प्रतिनिधिमंडल के मामले में, प्रत्यायोजित कार्यक्षमता की मात्रा पर निर्णय एग्रीगेटर वर्ग द्वारा अशुद्धियों के मामले में किया जाता है।



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



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



अब देखते हैं कि अशुद्धियों और प्रतिनिधिमंडल द्वारा समान अवसरों को कैसे लागू किया जा सकता है।

उदाहरण "ORM में व्यवहार"।

हमने अपने काल्पनिक ढांचे पर एक छोटी सी साइट बनाई। इस साइट पर लेखों की एक सूची है। हमारे ढांचे में ओआरएम है, जिसमें "लेख" का एक मॉडल है। हमारे ORM में सामान्य व्यवहार का समर्थन करने वाली कक्षाएं भी शामिल हैं: पेड़, संस्करण, नरम-निष्कासन, और इसी तरह।



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



फ्रेमवर्क के अगले संस्करण में, हमें मॉडल में वर्जनिंग और सॉफ्ट रिमूवल को जोड़ने की आवश्यकता है। जिसे हम आसानी से मॉडल में उपयुक्त अशुद्धियों को मिलाकर या प्रतिनिधिमंडल का उपयोग करके मॉडल वर्ग का विस्तार करके करते हैं।



ध्यान दें कि इस उदाहरण में अशुद्धियों और प्रतिनिधिमंडल दोनों का उपयोग किया जा सकता है।



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



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



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



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



जब आप अपने हाथों से कोड को नियंत्रित करते हैं, तो जाहिर है, आपको अशुद्धियों पर जाना होगा, या समस्या को हल करने के अन्य तरीकों की तलाश करनी होगी, क्योंकि यह स्पष्ट है कि प्रतिनिधिमंडल का उपयोग करने वाला उपरोक्त समाधान जटिल दिखेगा।



मुझे खेद है कि मैंने उन तकनीकी-प्रेमियों को निराश किया हो सकता है, जिन्होंने मेरे मूल गढ़ की रक्षा करने वाले दृष्टिकोणों में से एक के भयंकर समर्थकों के बीच मुझे देखने की उम्मीद की थी। मुझे खेद है अगर ऐसा है।



याद रखें कि जीवन में किसी भी विकल्प को हमेशा बनाया जाना चाहिए, दो चीजों द्वारा निर्देशित: अधिकतम जानकारी जो आप इस मुद्दे और अपने स्वयं के सिर पर एकत्र कर सकते हैं। मैंने पहले प्रदान करने की कोशिश की। दूसरा तुम्हारा है।



PS यदि यह लेख आपको रोचक लगा, तो अगली टिप्पणी के लिए विषय पर सुझाव दें।