पूर्वज (गंदा हैक)

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

---

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

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

मैं चाहता हूं कि सब कुछ सरल हो, और एक ही समय में जितना संभव हो उतना लचीला हो।
और ऐसा समाधान पाया गया:

सामान्य तौर पर, विचार चप्पल के रूप में सरल है:

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

यह सब अतीत में है!

अंत में, एक समय आया जब php 5.3 अधिकांश होस्टिंग साइटों पर उपलब्ध हो गया, और पुरानी शाखाओं के साथ संगतता प्रदान करने की कोई आवश्यकता नहीं थी।
लेकिन 5.3 में, SPL मॉड्यूल कर्नेल का हिस्सा है, और डिफ़ॉल्ट रूप से उपलब्ध है।
यह पता चला है कि डेवलपर्स ने पहले से ही इस विचार को spl_autoload_register फ़ंक्शन के रूप में लागू किया है।
Spl_autoload_register फ़ंक्शन समान कार्यों के ढेर पर हमारे ऑटोलॉड फ़ंक्शन को बस लॉग करता है।
इस प्रकार यदि हम एक फ़ंक्शन लिखते हैं जो मुख्य फ़ंक्शन को लोड करने से पहले संशोधित कक्षा को लोड करता है, तो हमारा कोड लोड किया जाएगा और मानक एक नहीं। दूसरी ओर, यदि हम कोड ऑटो-जेनरेशन के लिए कुछ विकल्प जोड़ना चाहते हैं, तो हम उन्हें मुख्य कोड के बाद जोड़ सकते हैं।

पर्याप्त सिद्धांत

जाहिर है, सभी पुनर्निर्धारित वर्गों को ऑटोलॉड के माध्यम से लोड किया जाना चाहिए और सीधे नहीं।

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

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

उदाहरण

सभी सामान्य कोड वाली सामान्य .php फ़ाइल:

function start_module() { //      ....   common.php    index.php } function mainAutoload($class) { //    $filename = './class/'.$class.'.php'; if(file_exists()) require_once($filename); } 

डिफ़ॉल्ट रूप से, index.php में शामिल हैं:

 require_once 'common.php'; // //     spl_autoload_register('mainAutoload'); // //      start_module(); 

मान लीजिए कि हम तय करते हैं कि हमारी परियोजना में कई ऐसे लोग होंगे जो आत्मा वर्ग को खत्म करना चाहते हैं
तब हम आत्मा को बनाते हैं। एफपी वर्ग:

 class soul extends soul_basic { //   . } 

और तदनुसार soul_basic.php

 class soul_basic { public function good() { //       } public function evil() { //    } public function saintliness() { //    } public function business() { //    } } 

ठीक है, पहले से ही विशिष्ट वस्तुओं को "आत्मा" की आवश्यकता होगी जो आत्मा से नहीं आत्मा से लागू कर सकते हैं या विरासत में ले सकते हैं, और आत्मा_बासिक में कार्यशीलता है।

अब कल्पना कीजिए कि हम सभी "आत्माओं" के व्यवहार को बदलना चाहते हैं।
जाहिर है, एक प्रोग्रामर या निर्देशक या किसी अन्य वर्ग की "आत्मा" के गुणों को पुनर्परिभाषित करना जो आत्मा से विरासत में मिले, हमारी मदद नहीं करेगा। इसलिए, हम अपनी आत्मा की कक्षा बनाते हैं। ऐसा करने के लिए, हम index.php फ़ाइल को संशोधित करते हैं, उदाहरण के लिए इस तरह:

 require_once 'common.php'; // //    . function century21Autoload($class) { if($class = 'soul') require_once('soul21.php'); } // //    spl_autoload_register('century21Autoload'); //     spl_autoload_register('mainAutoload'); // //      start_module(); 

अच्छी तरह से और तदनुसार soul21.php:

 class soul extends soul_basic { public function good() { if(rand(0,100)>=80) parent::good(); else parent::evil(); } public function saintliness() { if($this->unit_name == 'Gundyaev') parent::bussiness(); else parent::saintliness(); } } 

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