एक प्लगइन विकसित करते समय नामस्थान संघर्षों से बचने के लिए कार्यों को एक कक्षा में एक साथ रखा जाना चाहिए?
हां, लेकिन यह केवल एक मामूली तर्क है। वास्तव में यह OOAD में एक वर्ग की "सत्य" प्रकृति नहीं है ।
क्या कक्षाओं का उपयोग करना PHP के लिए प्रदर्शन ओवरहेड्स बनाता है?
नहीं, विशेष रूप से नहीं। खराब डिज़ाइन और / या खराब लिखित कोड या पूर्व-परिपक्व अनुकूलन वास्तविक भाषा सुविधाओं की तुलना में कहीं अधिक प्रदर्शन की समस्याएं पैदा करता है।
यदि कोई प्रदर्शन हिट होता है, तो क्या इसके बजाय नाम पूर्व निर्धारित होना चाहिए?
जैसा कि लिखा गया है, कोई प्रदर्शन हिट नहीं है। खराब लिखित कोड अच्छे लिखित कोड की तुलना में एक प्रदर्शन हिट से अधिक होगा जिसमें कोड की कुछ और लाइनें होती हैं, लेकिन आपको बुरे काम करने के लिए मजबूर नहीं करती हैं।
जमीनी स्तर:
आप प्लगइन्स के लिए कक्षाओं का अलग-अलग उपयोग कर सकते हैं। आप उन्हें केवल कुछ प्रकार के नामस्थान रखने के लिए उपयोग कर सकते हैं और उन्हें वैश्विक कार्यों के लिए "बस" का उपयोग कर सकते हैं। इसका सबसे प्रत्यक्ष रूप स्टेटिक क्लास फ़ंक्शंस हैं, निम्न कोड-उदाहरण दोनों को दिखाता है, पहले वैश्विक फ़ंक्शंस, फिर ग्लोबल स्टैटिक क्लास फ़ंक्शंस:
/* global function */
function myplug_hook()
{
}
add_filter('the_hook', 'myplug_hook');
/* global static function */
class myplug
{
public static function hook()
{
}
}
add_filter('the_hook', 'myplug::hook');
यह केवल एक छोटा सा उदाहरण है जो बताता है कि आपको सिंगल हुक के लिए अधिक टाइप करने की आवश्यकता है। इसके अतिरिक्त यह दिखाता है कि नाम स्थान कैसे काम करता है: आप सभी स्थिर कार्यों का नाम बदलने के लिए एकल वर्ग के नाम को आसानी से बदल सकते हैं और फिर खोज सकते हैं और बदल myplug::सकते हैं जो myplug_झूठी सकारात्मकता के कारण कठिन हो सकता है । लेकिन अंत में बहुत अंतर नहीं है।
मुख्य बिंदु यह है: स्थिर वर्ग फ़ंक्शंस डॉक्स वास्तव में बहुत अधिक नहीं हैं तो वैश्विक फ़ंक्शंस डॉक्स ।
और यह उदाहरण भी दिखाता है: नेमस्पेसिंग ठीक है, लेकिन वर्पड्रेस के साथ, नाम स्थान हुक के उपयोग से बंद हो जाता है: कॉलबैक फ़ंक्शन हार्डकोडेड है, इसलिए कक्षा का उपयोग करके नाम स्थान में लाभ (आधार-नाम के लिए एक स्थान, क्लासनाम) नहीं करता है जब आप हुक नामों के लिए अपने कोड को वर्डप्रेस के साथ हस्तक्षेप करने में मदद करें।
वास्तविक लाभ वास्तविक वर्ग के उदाहरणों और गैर-स्थिर कार्यों का उपयोग करने से शुरू होता है। इसका लाभ यह है कि आप ओओ सिद्धांतों का उपयोग करना शुरू कर सकते हैं और आप अपने कोड को सुव्यवस्थित कर सकते हैं। स्टैटिक क्लास फ़ंक्शंस एक सॉल्यूशन इन्फैक्ट की तुलना में अधिक समस्या है।
तब यह सिंटैक्टिक शुगर से अधिक है।
मुख्य बिंदु यह है: कुछ ऐसा करें जो आपको कोड लिखने में मदद करे जो आप आसानी से कर सकते हैं और बनाए रख सकते हैं। ओवर-दर प्रदर्शन न करें, यह एक सामान्य गलती है। अधिक महत्वपूर्ण यह है कि आप ऐसा कोड लिखें जो पढ़ने और समझने में आसान हो, बस वही करें जो आपको चाहिए। हो सकता है कि यह प्रश्न और उत्तर इस संदर्भ में एक बड़ी तस्वीर के लिए सहायक हो: एकाधिक कस्टम मेटाबॉक्स सहायता ।
छोटे प्लग इन के साथ भी मेरे पास एक सामान्य दृष्टिकोण है, ताकि प्लगइन को इंस्टेंट करने के लिए एक स्टैटिक हेल्पर फंक्शन का उपयोग किया जा सके और बाकी तब प्लगइन के भीतर रहता है। यह मुख्य प्लगइन लॉजिक को एनकैप्सुलेट करने में मदद करता है और यह हुक के साथ नाम स्थान से लाभान्वित करता है साथ ही निजी सदस्यों को हुक के बीच फिर से उपयोग किया जा सकता है जो मानक वैश्विक कार्यों के साथ संभव नहीं है। निम्नलिखित कोड-उदाहरण पैटर्न दिखाता है:
<?php
/** Plugin Headers ... */
return MyPlugin::bootstrap();
class MyPlugin
{
/** @var MyPlugin */
static $instance;
static public function bootstrap() {
if (NULL === self::$instance) {
self::$instance = new __CLASS__;
}
return self::$instance;
}
# ...
}
यह एक सामान्य पैटर्न है जो मैं आधार प्लगइन फ़ाइल के लिए उपयोग करता हूं। एक ओर प्लगइन वर्ग वर्डप्रेस के लिए प्लगइन का प्रतिनिधित्व करता है और दूसरी ओर यह स्वयं के कोड के लिए ऑब्जेक्ट ओरिएंटेड प्रतिमानों का उपयोग करना शुरू करने की अनुमति देता है जो पूरी तरह से ऑब्जेक्ट ओरिएंटेड हो सकते हैं (लेकिन आवश्यकता नहीं है)। यह एक तरह का नियंत्रक है, अनुरोध (ओं) के रूप में पूरे वर्डप्रेस एपीआई के साथ इंटरफेस करता है।
जैसा कि उदाहरण से पता चलता है, प्लगइन का एक उदाहरण बनाया जाएगा। यह आपको वास्तविक प्लगइन को इनिशियलाइज़ करने के लिए कंस्ट्रक्टर डॉक्स ( __construct) जैसे ज्ञात कॉमन्स का उपयोग करने की अनुमति देता है :
# ...
class MyPlugin
{
# ...
public function __construct()
{
add_filter('the_hook', array($this, 'hook'));
}
public function hook()
{
}
# ...
}
जिस समय हुक पंजीकृत होता है, यह प्लगइन ऑब्जेक्ट पहले से ही इसके डिज़ाइन से लाभान्वित होता है: आप ठोस प्लगइन क्लासनाम के खिलाफ वास्तविक हुक फ़ंक्शन को हार्ड-कोड करना बंद कर चुके हैं । कॉलबैक के लिए ऑब्जेक्ट उदाहरण के लिए वर्ग के बंधन के कारण यह संभव है। ध्वनि जटिल, बस कह रही: $this है प्लगइन। हुक कॉलबैक में इस्तेमाल किया जा सकता है, हुकिंग कॉलबैक के रूप में रजिस्टरिंग क्लास तरीकों की तुलना करें ।
यह पैटर्न वर्डप्रेस के साथ इंटरफ़ेस को आसान बनाने की अनुमति देता है: इंजेक्शन हुक के नाम और जो डेटा वे प्रदान करते हैं, उसके लिए कम हो जाता है। फिर आप सीधे इस प्लगइन वर्ग में लागू करना शुरू कर सकते हैं या इसके खिलाफ अपने कार्यान्वयन को फिर से शुरू कर सकते हैं, इसलिए केवल प्लगइन वर्ग में कोड डालें जो कि वर्डप्रेस के खिलाफ आपके प्लग इन इंटरफ़ेस को परिभाषित करने के लिए न्यूनतम है, लेकिन वर्पड्रेस के सामान्य तर्क को अलग रखें। यह वह जगह है जहाँ मज़ा शुरू होता है और सबसे शायद यही कि प्रत्येक प्लगइन लेखक लंबे समय में क्या हासिल करना चाहता है।
तो worpdress के साथ कार्यक्रम नहीं है, लेकिन इसके खिलाफ है। के रूप में worpdress काफी लचीला है, के खिलाफ प्रोग्राम के लिए इंटरफ़ेस का वर्णन करने के लिए कोई आम या आसान नहीं है। एक आधार प्लगइन वर्ग इस भूमिका को ले सकता है, जिससे आप अपने स्वयं के कोड के लिए अधिक लचीलेपन की अनुमति देंगे जिससे आसान कोड और एक बेहतर प्रदर्शन होगा।
तो नाम-रिक्ति के लिए सिर्फ एक लाभ से अधिक है। सबसे अच्छा सुझाव मैं दे सकता हूं: स्वयं प्रयास करें। बहुत कुछ नहीं है आप ढीले होंगे, केवल नई चीजों की खोज करने के लिए।
जब आप अपने प्लगइन को संगत रखते हुए वर्डप्रेस के कुछ और प्रमुख अपडेट पास कर लेते हैं, तो आप शायद सबसे अधिक अंतर नोटिस करेंगे।
कैविएट : यदि आपका प्लगइन सीधे काम करने के लिए वर्डप्रेस के साथ एकीकृत करता है, तो एक या दो सार्वजनिक कार्यों का उपयोग करना आपके लिए बेहतर हो सकता है। नौकरी के लिए सही उपकरण लें।