Developers building Laravel applications are being urged to ditch the new keyword inside their controllers and switch to the Factory Method pattern. By moving object creation into dedicated factories, code becomes easier to extend, test, and maintain—benefits that matter as projects grow beyond a handful of endpoints.

क्यों new कीवर्ड एक छिपा हुआ जोखिम (liability) है

जब एक कंट्रोलर में ऐसी लाइन होती है 

$processor = new StripePaymentProcessor($config);

तो वह कंट्रोलर अब StripePaymentProcessor क्लास के साथ मजबूती से जुड़ (tightly coupled) जाता है। जहाँ भी पेमेंट प्रोसेसर की आवश्यकता होती है, वहाँ वह लाइन बार-बार दोहराई जाती है, जिससे कंस्ट्रक्शन लॉजिक (construction logic) पूरे कोडबेस में बिखर जाता है। यदि बाद में प्रोसेसर को किसी लॉगर (logger), कैश मैनेजर (cache manager), या किसी अलग कॉन्फ़िगरेशन फॉर्मेट की आवश्यकता होती है, तो उन सभी जगहों को अपडेट करना होगा। इसका परिणाम एक ऐसा नाजुक (fragile) कोड होता है जो बदलावों को स्वीकार नहीं करता और यूनिट टेस्ट में मॉक (mock) करना कठिन होता है।

Factory Method पैटर्न का समाधान

Factory Method पैटर्न डायरेक्ट इंस्टेंशिएशन (direct instantiation) को एक ऐसे मेथड से बदल देता है जो एक दिए गए इंटरफ़ेस (interface) का इंस्टेंस (instance) रिटर्न करता है। कंट्रोलर इंटरफ़ेस पर निर्भर करता है, जबकि एक फैक्ट्री क्लास जानती है कि किस कंक्रीट क्लास (concrete class) को बनाना है और उसकी डिपेंडेंसीज़ (dependencies) को कैसे असेंबल करना है। सारा क्रिएशन लॉजिक एक ही जगह रहता है, इसलिए नई डिपेंडेंसी जोड़ना या इम्प्लीमेंटेशन बदलना केवल फैक्ट्री को प्रभावित करता है।

मुख्य लाभ

  • Loose coupling – कंट्रोलर्स एब्स्ट्रैक्शन (abstractions) के आधार पर काम करते हैं, न कि कंक्रीट क्लासेस के।
  • Centralized construction – बिल्ड प्रोसेस को बदलने के लिए केवल एक ही फाइल को एडिट करने की आवश्यकता होती है।
  • Testability – फैक्टरीज को स्टब (stub) किया जा सकता है या मोंक (mocks) से बदला जा सकता है, जिससे आइसोलेटेड कंट्रोलर टेस्ट संभव हो पाते हैं।
  • Open/Closed Principle – मौजूदा कंट्रोलर कोड को छुए बिना नई सुविधाएँ (जैसे, एक नया पेमेंट गेटवे) जोड़ी जा सकती हैं।

एक कॉफी शॉप का उदाहरण (analogy)

एक ऐसे बरिस्ता की कल्पना करें जिसे हर ऑर्डर के लिए if-else स्टेटमेंट्स की एक लंबी श्रृंखला का उपयोग करके मैन्युअल रूप से बीन्स पीसने, दूध स्टीम करने और पानी डालने की आवश्यकता होती है। यदि लाटे (latte) की रेसिपी बदलती है, तो हर बरिस्ता को स्टेप्स फिर से सीखने होंगे। एक कॉफी मशीन जो ऑर्डर का प्रकार प्राप्त करती है और आंतरिक रूप से तैयारी संभालती है, इस समस्या का समाधान करती है: बरिस्ता बस मशीन को बताता है कि क्या चाहिए, और मशीन सभी स्टेप्स को एनकैप्सुलेट (encapsulate) कर लेती है। अब रेसिपी अपडेट करने का मतलब मशीन को एडजस्ट करना है, न कि हर बरिस्ता को।

Laravel पहले से ही फैक्टरीज का उपयोग करता है

Laravel के अपने कोर कंपोनेंट्स इस पैटर्न के क्रियान्वयन को दर्शाते हैं:

  • Database – ConnectionFactory तय करता है कि MySQL या PostgreSQL कनेक्शन बनाना है।
  • Queues – QueueManager Redis, SQS, या अन्य बैक-एंड्स के लिए ड्राइवर्स बनाता है।
  • Filesystem – FilesystemManager लोकल या S3 डिस्क इंस्टेंस बनाता है।
  • Mail – MailManager SMTP, Mailgun, या अन्य मेल ड्राइवर्स को रिज़ॉल्व करता है।

यदि फ्रेमवर्क इन महत्वपूर्ण सेवाओं के लिए फैक्टरीज पर भरोसा करता है, तो कस्टम कोड को भी इसी का पालन करना चाहिए।

फैक्ट्री कब पेश करें

फैक्ट्री का उपयोग तब करें जब:

  • ऑब्जेक्ट क्रिएशन में कई कॉन्फ़िगरेशन स्टेप्स या बाहरी सेवाएं शामिल हों।
  • कई इंटरचेंजेबल (interchangeable) इम्प्लीमेंटेशन मौजूद हों (जैसे अलग-अलग पेमेंट गेटवे, स्टोरेज प्रोवाइडर, आदि)।
  • संभावित इम्प्लीमेंटेशन की सूची बढ़ने की उम्मीद हो।

फैक्ट्री से कब बचें:

  • जब कंस्ट्रक्शन बिना किसी अतिरिक्त सेटअप के एक सिंगल, इम्यूटेबल (immutable) new कॉल हो।
  • जब केवल एक ही इम्प्लीमेंटेशन का उपयोग किया जाएगा, जिससे अतिरिक्त एब्स्ट्रैक्शन अनावश्यक ओवरहेड बन जाता है।

क्विक वॉक-थ्रू: एक पेमेंट कंट्रोलर को रिफैक्टर करना

  1. एक इंटरफ़ेस परिभाषित करें – process(array $data) मेथड के साथ PaymentProcessorInterface।
  2. कंक्रीट क्लासेस को लागू करें – StripePaymentProcessor, PayPalPaymentProcessor, जिनमें से प्रत्येक इंटरफ़ेस को पूरा करती हो।
  3. एक फैक्ट्री बनाएं – make(string $driver): PaymentProcessorInterface मेथड के साथ PaymentProcessorFactory। इसके अंदर, उपयुक्त क्लास रिटर्न करने के लिए switch या मैप का उपयोग करें, और Laravel के सर्विस कंटेनर से आवश्यक सेवाओं को इंजेक्ट करें।
  4. फैक्ट्री को इंजेक्ट करें – कंट्रोलर के कंस्ट्रक्टर में, PaymentProcessorFactory को टाइप-हिंट (type-hint) करें। Laravel इसे स्वचालित रूप से रिज़ॉल्व कर देगा।
  5. फैक्ट्री का उपयोग करें – $processor = $this->processorFactory->make('stripe'); $processor->process($request->all());

अब कंट्रोलर में कभी भी new या किसी कंक्रीट प्रोसेसर का उल्लेख नहीं होता है। एक नया गेटवे जोड़ने का मतलब है एक क्लास बनाना और फैक्ट्री के मैप को बढ़ाना—कंट्रोलर में कोई बदलाव करने की आवश्यकता नहीं है।

संभावित कमियां और उन्हें कैसे कम किया जाए

फैक्ट्रियों की मुख्य आलोचना यह है कि वे एक अतिरिक्त indirection जोड़ती हैं, जो मामूली ऑब्जेक्ट्स के लिए बहुत अधिक verbose लग सकती है। एक साधारण सर्विस की over-engineering बिना किसी वास्तविक लाभ के codebase को बढ़ा सकती है। मुख्य बात निर्माण की जटिलता का आकलन करना है: यदि कोई ऑब्जेक्ट बिना किसी dependency के केवल एक साधारण data holder है, तो सीधे new का उपयोग करना स्वीकार्य हो सकता है। इसके अलावा, फैक्ट्रियां असंबंधित logic के लिए एक dumping ground बन सकती हैं। फैक्ट्रियों को केवल object creation पर केंद्रित रखना और configuration को समर्पित service providers को सौंपना स्पष्टता बनाए रखता है।

आगे किन बातों का ध्यान रखें

  • Service container bindings – यदि आप service provider में interface को factory class से bind करते हैं, तो Laravel का container स्वचालित रूप से factories को resolve कर सकता है।
  • Auto-discovery – कुछ packages अपनी खुद की factories प्रदान करते हैं; naming collisions के प्रति सचेत रहें।
  • Testing strategies – Controllers की unit testing करते समय, factory को एक mock से बदल दें जो एक stubbed processor लौटाता हो, जिससे यह सुनिश्चित हो सके कि tests तेज़ और isolated रहें।

निष्कर्ष

बिखरे हुए new calls को एक सही जगह पर रखी गई factory से बदलने से निर्माण केंद्रीकृत हो जाता है, coupling कम होती है, और custom code Laravel के अपने design philosophy के अनुरूप हो जाता है। उन टीमों के लिए जो विकास की उम्मीद करती हैं—जैसे नए payment providers, storage back-ends, या कोई भी plug-in-style component—Factory Method pattern एक कम लागत वाला निवेश है जो flexibility और आत्मविश्वास के रूप में लाभ देता है। आपका भविष्य का स्वरूप, और वह कोई भी जो इस कोड को आगे बढ़ाएगा, आपको धन्यवाद देगा।