2009-07-20 12 views
16

निम्नलिखित कोड एक ट्यूटोरियल (http://net.tutsplus.com/php/creating-a-php5-framework-part-1/) से है, मेरा नहीं।रजिस्ट्री डिजाइन पैटर्न ... अच्छा या बुरा?

मैं इस कोड के बारे में कुछ प्रश्न हैं ...

  • लेख यह "रजिस्ट्री डिजाइन पैटर्न" उपयोग कर रहा है का दावा है; क्या यह उद्योग में इस डिजाइन के लिए सार्वभौमिक नाम है?
  • क्या वहां कोई और समान पटर है जो बेहतर विकल्प होगा?
  • क्या यह पैटर्न एक एमवीसी ढांचे के संदर्भ में लागू करने के लिए अच्छा अभ्यास माना जाता है?

मैं सिर्फ यह जानना चाहता हूं कि मुझे एमवीसी ढांचे के अपने कार्यान्वयन में इस डिजाइन पैटर्न का उपयोग करना चाहिए या नहीं। धन्यवाद!

<?php 
/** 
* The PCARegistry object 
* Implements the Registry and Singleton design patterns 
* @version 0.1 
* @author Michael Peacock 
*/ 
class PCARegistry { 

/** 
* Our array of objects 
* @access private 
*/ 
private static $objects = array(); 

/** 
* Our array of settings 
* @access private 
*/ 
private static $settings = array(); 

/** 
* The frameworks human readable name 
* @access private 
*/ 
private static $frameworkName = 'PCA Framework version 0.1'; 

/** 
* The instance of the registry 
* @access private 
*/ 
private static $instance; 

/** 
* Private constructor to prevent it being created directly 
* @access private 
*/ 
private function __construct() 
{ 

} 

/** 
* singleton method used to access the object 
* @access public 
* @return 
*/ 
public static function singleton() 
{ 
    if(!isset(self::$instance)) 
    { 
     $obj = __CLASS__; 
     self::$instance = new $obj; 
    } 

    return self::$instance; 
} 

/** 
* prevent cloning of the object: issues an E_USER_ERROR if this is attempted 
*/ 
public function __clone() 
{ 
    trigger_error('Cloning the registry is not permitted', E_USER_ERROR); 
} 

/** 
* Stores an object in the registry 
* @param String $object the name of the object 
* @param String $key the key for the array 
* @return void 
*/ 
public function storeObject($object, $key) 
{ 
    require_once('objects/' . $object . '.class.php'); 
    self::$objects[ $key ] = new $object(self::$instance); 
} 

/** 
* Gets an object from the registry 
* @param String $key the array key 
* @return object 
*/ 
public function getObject($key) 
{ 
    if(is_object (self::$objects[ $key ])) 
    { 
     return self::$objects[ $key ]; 
    } 
} 

/** 
* Stores settings in the registry 
* @param String $data 
* @param String $key the key for the array 
* @return void 
*/ 
public function storeSetting($data, $key) 
{ 
    self::$settings[ $key ] = $data; 


} 

/** 
* Gets a setting from the registry 
* @param String $key the key in the array 
* @return void 
*/ 
public function getSetting($key) 
{ 
    return self::$settings[ $key ]; 
} 

/** 
* Gets the frameworks name 
* @return String 
*/ 
public function getFrameworkName() 
{ 
    return self::$frameworkName; 
} 


} 

?> 
+0

LOL ... मैं उठ गया और उसके बाद मतदान मतदान किया। मान लीजिए कि मेरा प्रश्न किसी के लिए पर्याप्त नहीं है। –

उत्तर

25

लेख का दावा है कि यह "रजिस्ट्री डिजाइन पैटर्न" उपयोग कर रहा है; क्या यह उद्योग में इस डिजाइन के लिए सार्वभौमिक नाम है?

हां, लेकिन कार्यान्वयन स्पष्ट रूप से भिन्न हो सकता है। असल में, एक रजिस्ट्री साझा वस्तुओं के लिए एक कंटेनर है। वास्तव में मूल संस्करण में, आप एक सरणी का उपयोग कर सकते हैं। इस प्रकार, परिवर्तनीय $GLOBALS को रजिस्ट्री कहा जा सकता है।

क्या वहां एक और समान पटर है जो बेहतर विकल्प होगा?

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

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

क्या यह पैटर्न एक एमवीसी ढांचे के संदर्भ में लागू करने के लिए अच्छा अभ्यास माना जाता है?

यह सामान्य प्रथा है। यदि यह अच्छा या बुरा है तो एक निर्णय कॉल है। व्यक्तिगत रूप से मैं decoupling की वापसी में कुछ जटिलता स्वीकार करने के लिए तैयार हूँ, लेकिन ymmv।

5

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

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

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

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

अविवेक बचाया आप काम करते हैं, आवश्यक कोड की राशि कम, और अंत में अपने सॉफ्टवेयर, सस्ता बेहतर और तेज कर दिया।

इसके साथ, ऐसे समय होते हैं जब दो पैटर्न सीधे अंतर-परिवर्तनीय नहीं होते हैं। आइए उदाहरण के लिए आप एक प्रकार का ढांचा तैयार कर रहे हैं जो ईवेंट हैंडलर को एक्सएमएल दस्तावेज़ के नोड्स से जोड़ता है। आप XPath या JQuery के सीएसएस चयनकर्ताओं के कार्यान्वयन का उपयोग कर किसी XML दस्तावेज़ में नोड्स के स्थानों का वर्णन करते हैं। लेकिन एक ईवेंट हैंडलर संलग्न करने के लिए, आपको कुछ कोड को भी संदर्भित करने की आवश्यकता है। अधिमानतः, आप किसी ऑब्जेक्ट की कुछ विधि देखेंगे - ठीक है, इसे "कुछ ऑब्जेक्ट" नाम देने के बिना कोई रास्ता नहीं है, इसलिए अब आपको एक सेवा लोकेटर की आवश्यकता है, ताकि आप चीजों को नाम से देख सकें। लेकिन ध्यान रखें कि यहां तक ​​कि इस उदाहरण में, यह भी निर्धारित नहीं है कि नाम वैश्विक होना चाहिए।

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

संबंधित मुद्दे