एक PHP परियोजना में, सहायक वस्तुओं को संग्रहीत, एक्सेस और व्यवस्थित करने के लिए कौन से पैटर्न मौजूद हैं? [बन्द है]

Question

आप डेटाबेस इंजन, उपयोगकर्ता अधिसूचना, त्रुटि से निपटने और एक PHP आधारित, वस्तु उन्मुख परियोजना जैसे अपने सहायक वस्तुओं को कैसे व्यवस्थित और प्रबंधित करते हैं?

कहो कि मेरे पास एक बड़ा PHP CMS है। CMS विभिन्न वर्गों में आयोजित किया जाता है। कुछ उदाहरण:

• डेटाबेस ऑब्जेक्ट
• उपयोगकर्ता प्रबंधन
• आइटम बनाने / संशोधित करने / हटाने के लिए एक एपीआई
• संदेश को अंतिम उपयोगकर्ता को प्रदर्शित करने के लिए एक संदेश वस्तु
• एक संदर्भ हैंडलर जो आपको सही पृष्ठ पर ले जाता है
• एक नेविगेशन बार वर्ग जो बटन दिखाता है
• एक लॉगिंग ऑब्जेक्ट
• संभवतः, कस्टम त्रुटि हैंडलिंग

आदि।

मैं शाश्वत प्रश्न के साथ काम कर रहा हूं कि इन वस्तुओं को सिस्टम के प्रत्येक हिस्से तक कैसे पहुंच योग्य बनाया जाए जो इसकी आवश्यकता है।

मेरा पहला ऐपॉर्च, कई साल पहले एक $ अनुप्रयोग वैश्विक था जिसमें इन वर्गों के प्रारंभिक उदाहरण शामिल थे।

global $application;
$application->messageHandler->addMessage("Item successfully inserted");

मैं तब सिंगलटन पैटर्न और एक फैक्ट्री फंक्शन में बदल गया:

$mh =&factory("messageHandler");
$mh->addMessage("Item successfully inserted");

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

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

अधिकांश PHP फ्रेमवर्क जो मैंने सिंगलटन पैटर्न, या फ़ंक्शंस में उपयोग किए गए हैं, जो आरंभीकृत वस्तुओं तक पहुंचते हैं। दोनों ठीक हैं, लेकिन जैसा कि मैंने कहा कि मैं न तो खुश हूं।

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

इसके अलावा, मैं इस मुद्दे पर विशेष, आला या सादे अजीब दृष्टिकोण के बारे में सुनने के लिए इच्छुक हूं ।

Comments

मैंने बस एक ऐसा ही सवाल पूछा, जिसमें एक इनाम भी था। आप वहां कुछ उत्तरों की सराहना कर सकते हैं: stackoverflow.com/questions/1967548/…

— फिल्पेरो

बस एक हेड अप, एक नई वस्तु को संदर्भ द्वारा लौटाता है - जैसे $mh=&factory("messageHandler");कि व्यर्थ है और कोई प्रदर्शन लाभ नहीं देता है। इसके अलावा, यह 5.3 में पदावनत है।

— राईगुए

Answer 1

मैं Flavius ​​द्वारा सुझाए गए सिंगलटन दृष्टिकोण से बचूंगा। इस दृष्टिकोण से बचने के कई कारण हैं। यह ओओपी के अच्छे सिद्धांतों का उल्लंघन करता है। Google परीक्षण ब्लॉग में सिंगलटन पर कुछ अच्छे लेख हैं और इससे कैसे बचा जाए:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-use-d dependancy -injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

वैकल्पिक

1. एक सेवा प्रदाता

   http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2. निर्भरता अन्तःक्षेपण

   http://en.wikipedia.org/wiki/Dependency_injection

   और एक php स्पष्टीकरण:

   http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

यह इन विकल्पों के बारे में एक अच्छा लेख है:

http://martinfowler.com/articles/injection.html

निर्भरता इंजेक्शन (DI) को लागू करना:

• मेरा मानना ​​है कि आपको यह पूछना चाहिए कि निर्माणकर्ता को कार्य करने के लिए क्या आवश्यक है :new YourObject($dependencyA, $dependencyB);

• आप आवश्यक वस्तुओं (निर्भरता) को मैन्युअल रूप से ( $application = new Application(new MessageHandler()) प्रदान कर सकते हैं । लेकिन आप डीआई फ्रेमवर्क का उपयोग भी कर सकते हैं (विकिपीडिया पेज PHP DI फ्रेमवर्क के लिंक प्रदान करता है )।

  महत्वपूर्ण यह है कि आप केवल उसी चीज में पास होते हैं जिसका आप वास्तव में उपयोग करते हैं (कॉल एक्शन ऑन), न कि आप केवल अन्य वस्तुओं के पास जाते हैं क्योंकि उन्हें इसकी आवश्यकता होती है। यहाँ 'अंकल बॉब' (रॉबर्ट मार्टिन) की एक हालिया पोस्ट में मैनुअल DI बनाम फ्रेमवर्क का उपयोग करने पर चर्चा की गई है ।

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

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

मुझे पता है कि बहुत से लोग इसे करते हैं, इसे स्वीकार करते हैं और इसका उपयोग करते हैं। लेकिन Misko Heverys ब्लॉग लेख ( एक गूगल परीक्षण क्षमता विशेषज्ञ) पढ़ना ) को पढ़ना, इसे करना और धीरे-धीरे पचाना जो वह कहता है कि मैंने डिजाइन को देखने के तरीके को बदल दिया है।

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

मैं अभी भी उस ब्लॉग से मिली सारी जानकारी से जूझ रहा हूँ , और इसे लागू करना हमेशा आसान नहीं होता है, और मेरे पास कई सवाल हैं। लेकिन कोई रास्ता नहीं है कि मैं वापस जा सकता हूं जो मैंने पहले किया था (हाँ, वैश्विक राज्य और सिंगलेट्स (बिग एस)) के बाद मैंने मिस्साक हेवरी को जो कहा था उसे समझ लिया :-)

Comments

DI के लिए +1। यद्यपि मैं इसका उतना उपयोग नहीं करता, जितना मैं करना चाहता हूं, लेकिन जो भी छोटी मात्रा में मैंने इसका उपयोग किया, वह बहुत उपयोगी है।

— अनुराग

@ पता: PHP में DI / SP कार्यान्वयन का PHP उदाहरण देने के लिए देखभाल? शायद @Flavius ​​कोड आपके द्वारा सुझाए गए वैकल्पिक पैटर्न का उपयोग करके लागू किया गया है?

— अलिक्स एक्सल

मेरे जवाब में DI कार्यान्वयन और कंटेनर के लिए एक लिंक जोड़ा गया।

— थॉमस

मैं यह सब अब पढ़ रहा हूं, लेकिन मैंने यह सब अभी तक पढ़ा है, मैं पूछना चाहता हूं, क्या एक निर्भरता इंजेक्शन ढांचा मूल रूप से एक रजिस्ट्री होगा?

— जेसनडेविस

नहीं वास्तव में नहीं। लेकिन एक निर्भरता इंजेक्शन कंटेनर एक रजिस्ट्री के रूप में भी सेवित हो सकता है। मैंने अपने उत्तर में जो लिंक्स पोस्ट किए हैं, उन्हें बस पढ़ें। डीआई का अनुमान वास्तव में व्यावहारिक रूप से समझाया गया है।

— थॉमस

Answer 2

class Application {
    protected static $_singletonFoo=NULL;

    public static function foo() {
        if(NULL === self::$_singletonFoo) {
            self::$_singletonFoo = new Foo;
        }
        return self::$_singletonFoo;
    }

}

इस तरह से मैं यह करूँगा। यह मांग पर वस्तु बनाता है:

Application::foo()->bar();

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

ध्यान दें : मैंने जो प्रस्तुत किया है वह वास्तविक सिंगलटन पैटर्न भी नहीं है। एक सिंगलटन कंस्ट्रक्टर (Foo :: __ कंस्ट्रक्टर ()) को निजी बताकर केवल एक ही उदाहरण की अनुमति देगा। यह केवल "अनुप्रयोग" उदाहरणों के लिए उपलब्ध "वैश्विक" चर है। इसलिए मुझे लगता है कि इसका उपयोग वैध है क्योंकि यह अच्छे ओओपी सिद्धांतों की अवहेलना नहीं करता है। बेशक, दुनिया में कुछ भी, इस "पैटर्न" का अति प्रयोग नहीं किया जाना चाहिए!

मैंने देखा है कि यह कई PHP फ्रेमवर्क, ज़ेंड फ्रेमवर्क और Yii में इस्तेमाल किया जा रहा है। और आपको एक रूपरेखा का उपयोग करना चाहिए। मैं आपको बताने वाला नहीं हूं कि कौन सा है।

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

class Application {
        protected static $_singletonFoo=NULL;
        protected static $_helperName = 'Foo';

        public static function setDefaultHelperName($helperName='Foo') {
                if(is_string($helperName)) {
                        self::$_helperName = $helperName;
                }
                elseif(is_object($helperName)) {
                        self::$_singletonFoo = $helperName;
                }
                else {
                        return FALSE;
                }
                return TRUE;
        }
        public static function foo() {
                if(NULL === self::$_singletonFoo) {
                        self::$_singletonFoo = new self::$_helperName;
                }
                return self::$_singletonFoo;
        }
}

सुधार के लिए पर्याप्त जगह है। यह सिर्फ एक PoC है, अपनी कल्पना का उपयोग करें।

ऐसा क्यों है? खैर, ज्यादातर समय एप्लिकेशन को यूनिट-परीक्षण नहीं किया जाएगा, यह वास्तव में एक उत्पादन वातावरण में चलाया जाएगा । PHP की ताकत इसकी गति है। PHP नहीं है और कभी भी जावा की तरह एक "स्वच्छ ओओपी भाषा" नहीं होगी।

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

स्टीरियोटाइप्ड "नियम" जैसे "सिंगलटन खराब हैं" बुराई का स्रोत हैं, वे आलसी लोगों के लिए हैं जो खुद के लिए सोचने के लिए तैयार नहीं हैं।

हाँ, मुझे पता है, PHP मेनिफेस्टो BAD है, तकनीकी रूप से बोल रहा हूँ। फिर भी यह एक सफल भाषा है, इसके हैकिश तरीके से।

परिशिष्ट

एक समारोह शैली:

function app($class) {
    static $refs = array();

    //> Dependency injection in case of unit test
    if (is_object($class)) {
        $refs[get_class($class)] = $class;
        $class = get_class($class);
    }

    if (!isset($refs[$class]))
        $refs[$class] = new $class();

    return $refs[$class];
}

//> usage: app('Logger')->doWhatever();

Comments

मैंने उत्तर को अस्वीकार कर दिया क्योंकि मेरा मानना ​​है कि समस्या को संभालने के लिए सिंगलटन पैटर्न का सुझाव देना ठोस OOP सिद्धांतों के खिलाफ जाता है।

— कोन्या

@ पता: आप जो कह रहे हैं वह सच है, आम तौर पर बोल रहा हूं, लेकिन जहां तक ​​मैंने उनकी समस्या को समझा है, वह आवेदन के लिए सहायकों के बारे में बात कर रहा है, और एक आवेदन के भीतर केवल एक ही है ... उह, आवेदन।

— फ्लेविअस

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

— फ्लाविस

-1 मुझसे भी। यह सिंगलटन डीपी का केवल एक आधा हिस्सा हो सकता है, लेकिन यह सबसे बदसूरत है: "इसे वैश्विक पहुंच प्रदान करें"।

— बस किसी को

यह वास्तव में उनके मौजूदा दृष्टिकोण को बहुत साफ करता है।

— डैनियल वॉन फंगे

Answer 3

मुझे डिपेंडेंसी इंजेक्शन की अवधारणा पसंद है:

"निर्भरता इंजेक्शन वह जगह है जहाँ घटकों को उनके निर्माणकर्ताओं, विधियों, या सीधे खेतों में के माध्यम से उनकी निर्भरता दी जाती है। ( पिको कंटेनर वेबसाइट से )"

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

जैसा कि ऊपर कहा गया है, मुझे सिंग्लेटन्स का उपयोग पसंद नहीं है। इस बात पर एक अच्छा सारांश कि क्यों सिंग्लेटन्स अच्छे डिज़ाइन नहीं हैं, स्टीव येजे के ब्लॉग में यहाँ पाए जा सकते हैं ।

Comments

मुझे PHP में क्लोज़र के माध्यम से कार्यान्वयन पसंद है, बहुत दिलचस्प पढ़ना

— जुराज ब्लाहुनका

मुझे भी उसकी साइट पर क्लोजर के संबंध में कुछ अन्य सामान की आवश्यकता है: fabien.potencier.org/article/17/…

— थॉमस

चलो आशा करते हैं, कि मुख्यधारा के वेबपोर्टल जल्द ही PHP 5.3 में माइग्रेट करेंगे, क्योंकि अभी भी एक पूर्ण विशेषताओं वाला php 5.3 सर्वर देखना आम नहीं है

— Juraj Blahunka

जब अधिक से अधिक परियोजनाओं के लिए PHP 5.3 की आवश्यकता होगी, जैसे Zend फ्रेमवर्क 2.0 की रूपरेखा

— थॉमस

निर्भरता इंजेक्शन भी सवाल के बारे में जवाब स्वीकार कर लिया गया decupling from GOD object: stackoverflow.com/questions/1580210/… बहुत अच्छे उदाहरण के साथ

— Juraj Blahunka

Answer 4

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

एकाकी वस्तु

अनुशंसित नहीं है क्योंकि यह एक वैश्विक राज्य का परीक्षण करना मुश्किल है। (Singletonitis)

रजिस्ट्री

सिंगलटनिटिस को खत्म करता है, बग मैं रजिस्ट्री की भी सिफारिश नहीं करता, क्योंकि यह एक तरह का सिंगलटन भी है। (इकाई परीक्षण के लिए कठिन)

विरासत

अफ़सोस की बात है, PHP में कोई बहु विरासत नहीं है, इसलिए यह सभी श्रृंखलाओं तक सीमित है।

निर्भरता अन्तःक्षेपण

यह एक बेहतर दृष्टिकोण है, लेकिन एक बड़ा विषय है।

परंपरागत

इसे करने का सबसे सरल तरीका है कंस्ट्रक्टर या सेटर इंजेक्शन (सेटर का उपयोग करके या क्लास कंस्ट्रक्टर में निर्भरता ऑब्जेक्ट का उपयोग करना)।

फ़्रेमवर्क

आप अपने स्वयं के निर्भरता इंजेक्टर को रोल कर सकते हैं, या कुछ निर्भरता इंजेक्शन फ्रेमवर्क का उपयोग कर सकते हैं, जैसे। Yadif

अनुप्रयोग संसाधन

आप अपने सभी संसाधनों को एप्लिकेशन बूटस्ट्रैप (जो एक कंटेनर के रूप में कार्य करता है) में इनिशियलाइज़ कर सकते हैं, और उन्हें बूटस्ट्रैप ऑब्जेक्ट तक पहुँचने वाले ऐप में कहीं भी एक्सेस कर सकते हैं।

यह Zend फ्रेमवर्क 1.x में लागू दृष्टिकोण है

संसाधन लोडर

एक प्रकार की स्थैतिक वस्तु जो जरूरत पड़ने पर ही संसाधन को लोड (बनाती) करती है। यह एक बहुत ही स्मार्ट दृष्टिकोण है। आप इसे कार्रवाई में देख सकते हैं जैसे कि सिम्फनी के डिपेंडेंसी इंजेक्शन घटक को लागू करना

विशिष्ट परत को इंजेक्शन

संसाधन हमेशा आवेदन में कहीं भी आवश्यक नहीं होते हैं। कभी-कभी आपको नियंत्रक (एमवी सी ) में उनकी आवश्यकता होती है । तब आप केवल वहाँ संसाधनों को इंजेक्ट कर सकते हैं।

इसके लिए सामान्य दृष्टिकोण इंजेक्शन मेटाडेटा को जोड़ने के लिए डॉकब्लॉक टिप्पणियों का उपयोग कर रहा है।

मेरा दृष्टिकोण यहां देखें:

ज़ेंड फ्रेमवर्क में निर्भरता इंजेक्शन का उपयोग कैसे करें? - स्टैक ओवरफ़्लो

अंत में, मैं यहां एक बहुत ही महत्वपूर्ण बात के बारे में एक नोट जोड़ना चाहूंगा - कैशिंग।
सामान्य तौर पर, आपके द्वारा चुनी गई तकनीक के बावजूद, आपको यह सोचना चाहिए कि संसाधनों को कैसे कैश किया जाएगा। कैश ही संसाधन होगा।

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

Answer 5

यदि आप वस्तुओं को विश्व स्तर पर उपलब्ध कराना चाहते हैं, तो रजिस्ट्री पैटर्न आपके लिए दिलचस्प हो सकता है। प्रेरणा के लिए, Zend रजिस्ट्री पर एक नज़र है ।

इसलिए रजिस्ट्री बनाम सिंगलटन प्रश्न भी।

Comments

यदि आप Zend फ्रेमवर्क का उपयोग नहीं करना चाहते हैं, तो यहां PHP5 के लिए रजिस्ट्री पैटर्न का अच्छा कार्यान्वयन है: phpbar.de/w/Registry

— थॉमस

मैं एक टाइप किया हुआ रजिस्ट्री पैटर्न पसंद करता हूं, जैसे रजिस्ट्री :: गेटडाबेस ("मास्टर"); रजिस्ट्री :: GetSession ($ उपयोगकर्ता-> SessionKey ()); रजिस्ट्री :: GetConfig ( "स्थानीय"); [...] और प्रत्येक प्रकार के लिए एक इंटरफ़ेस परिभाषित करना। इस तरह से आप यह सुनिश्चित करते हैं कि आप गलती से कुछ अलग करने के लिए उपयोग की जाने वाली कुंजी को अधिलेखित नहीं करते हैं (यानी आपके पास "मास्टर डेटाबेस" और "मास्टर कॉन्फ़िगरेशन" हो सकता है। इंटरफेस का उपयोग करके आप यह सुनिश्चित करते हैं कि केवल मान्य ऑब्जेक्ट का उपयोग किया जाता है। यहcc कर सकता है। कई रजिस्ट्री कक्षाओं का उपयोग करके भी लागू किया जा सकता है, लेकिन एक भी सरल और प्रयोग करने में आसान है, लेकिन अभी भी फायदे हैं।

— Morfildur

या बेशक एक PHP में बनाया - $ _GLOBALS

— Gnuffo1

Answer 6

PHP में ऑब्जेक्ट्स अच्छी मात्रा में मेमोरी लेते हैं, जैसा कि आपने शायद अपने यूनिट परीक्षणों से देखा है। इसलिए जितनी जल्दी हो सके गैर-जरूरी वस्तुओं को नष्ट करना आदर्श है अन्य प्रक्रियाओं के लिए स्मृति को बचाने के लिए है। इस बात को ध्यान में रखते हुए कि मुझे लगता है कि प्रत्येक वस्तु दो में से एक सांचे में फिट बैठती है।

1) ऑब्जेक्ट में कई उपयोगी तरीके हो सकते हैं या एक से अधिक बार कॉल करने की आवश्यकता होती है जिस स्थिति में मैं एक सिंगलटन / रजिस्ट्री को लागू करता हूं:

$object = load::singleton('classname');
//or
$object = classname::instance(); // which sets self::$instance = $this

2) ऑब्जेक्ट केवल उस पद्धति / फ़ंक्शन के जीवन के लिए मौजूद है, जिसमें यह कहा गया है कि वस्तु के संदर्भ को लंबे समय तक जीवित रखने से रोकने के लिए एक साधारण निर्माण फायदेमंद है।

$object = new Class();

अस्थायी वस्तुओं को संग्रहीत करने से कहीं भी मेमोरी लीक हो सकती है क्योंकि उनके संदर्भ को बाकी स्क्रिप्ट के लिए ऑब्जेक्ट को मेमोरी में रखने के बारे में भुलाया जा सकता है।

Answer 7

मैं प्रारंभिक वस्तुओं को लौटाने के लिए काम करूँगा:

A('Users')->getCurrentUser();

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

Answer 8

फाइन मैनुअल क्यों नहीं पढ़ा?

http://php.net/manual/en/language.oop5.autoload.php

Comments

धन्यवाद gcb, लेकिन कक्षाओं को लोड करना मेरी चिंता का विषय नहीं है, मेरा प्रश्न अधिक वास्तुकला प्रकृति का है।

— पेकाका

हालांकि यह सैद्धांतिक रूप से प्रश्न का उत्तर दे सकता है, लेकिन उत्तर के आवश्यक भागों को इसमें शामिल करना बेहतर होगा , और संदर्भ के लिए लिंक प्रदान करें।

— jjnguy