अनुवादक की प्रस्तावना
यह लेख पोस्ट ऑफ़ द ऑटोलडिंग का एक मुफ्त अनुवाद-रीटेलिंग है
। मूल लेख पहली ताजगी नहीं है, इसलिए उदाहरणों में कोड प्रासंगिक नहीं हो सकता है। लेख जिस विषय पर स्पर्श करता है, उसमें सबसे महत्वपूर्ण बात सामान्य दृश्य है, विशिष्ट उदाहरण नहीं।
प्रस्तावना
PHP स्टार्टअप एक बेहतरीन समय बचाने वाला है। यह आपको उन पुस्तकालयों के बारे में सोचे बिना स्क्रिप्ट लिखने की अनुमति देता है, जिनका आप उपयोग करते हैं। लेकिन नामस्थान के आगमन और आधुनिक रूपरेखाओं के जावा शैली के प्रभाव में, स्थिति बदल गई है। निकट भविष्य में, ऑटोलैड सर्वव्यापी होगा, लेकिन अपनी पुरानी शैली के एक भी लाभ के बिना।
स्टार्टअप से पहले। फ़ाइल पथ।
स्टार्टअप से पहले, प्रत्येक स्क्रिप्ट में उपयोग किए गए पुस्तकालयों के रास्तों को इंगित करना आवश्यक था। स्रोत कोड इस तरह दिखता है:
<?php require_once 'PEAR.php'; require_once 'PEAR/DependencyDB.php'; class PEAR_Registry extends PEAR {
प्रत्येक स्क्रिप्ट की शुरुआत में निर्भरता स्पष्ट रूप से लिखी गई थी। इस उदाहरण में, निर्भरता स्पष्ट है भले ही PEAR_D dependencyDB कॉल 328 लाइन पर है।
एसपीएल स्टार्टअप का आगमन।
बाद में, spl_autoload_register () फ़ंक्शन दिखाई दिया, जिसने कॉल करने के लिए आवश्यकता / आवश्यकता_ कॉल को निकालना संभव बना दिया। महान बात यह थी कि अब यह जानने की आवश्यकता के बिना कक्षाओं का उपयोग करना संभव था कि वे कहाँ स्थित हैं। उदाहरण के लिए:
<?php class postActions extends sfActions { public function executeList() { $this->posts = PostPeer::doSelect(new Criteria()); } }
देखिए, इस वर्ग की आवश्यकता / आवश्यकता के लिए एक भी कॉल नहीं है, इस तथ्य के बावजूद कि यह वर्ग sfActions, PostPeer और मानदंड वर्गों पर निर्भर है। डेवलपर्स निर्भरता के रास्तों की तलाश में समय बर्बाद किए बिना व्यापार तर्क करने में सक्षम थे। यह वास्तव में सुविधाजनक था।
स्टार्टअप कार्यान्वयन।
स्टार्टअप कार्यान्वयन अलग-अलग होते हैं। कुछ पुस्तकालय सभी वर्गों की एक सूची का उपयोग करते हैं जिन्हें कनेक्ट करने की आवश्यकता होती है। उदाहरण के लिए:
<?php class Propel {
इस तकनीक ने कक्षाओं के लिए रास्तों को छिपाना संभव बना दिया, लेकिन लाइब्रेरी डेवलपर को स्टार्टअप मैप को अपडेट करने के लिए मजबूर किया, हर बार एक नया वर्ग जोड़ा गया। एक अन्य तकनीक एक प्रोजेक्ट फ़ोल्डर संरचना पास का उपयोग करती है जो आपको आवश्यक वर्ग खोजने के लिए करता है। इस दृष्टिकोण ने फ्रेमवर्क कक्षाओं को अपने साथ बदलने की अनुमति दी, जैसा कि फ़ोल्डर नेविगेशन एक विशिष्ट क्रम में हुआ: उपयोगकर्ता फ़ोल्डर, प्रोजेक्ट, प्लगइन्स और फ्रेमवर्क। इस प्रकार, डेवलपर एक क्लासनेम वर्ग बना सकता है, जो प्लगइन द्वारा प्रदान किए गए क्लासनेम को बदल देगा, क्योंकि पहले बूट होगा।
नेमस्पेस आटोलाड
नेमस्पेस के आगमन ने स्टार्टअप तकनीकों को बदल दिया है। विभिन्न पुस्तकालयों के बीच तकनीकी बातचीत को सक्षम करने के लिए स्टार्टअप तकनीकों को एकजुट करने के लिए रूपरेखा के लेखक एकजुट हुए हैं। यह तय किया गया था कि स्पष्ट रूप से निहित से बेहतर है और पूर्ण वर्ग का नाम फ़ाइल के सापेक्ष पथ होगा।
\Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php \Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php \Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php \Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php
नामकरण और फ़ाइल संरचना के सिद्धांतों को विकसित किया गया था, साथ ही साथ
SplClassLoader वर्ग का कार्यान्वयन भी किया गया था। यह दृष्टिकोण अब लगभग सभी आधुनिक रूपरेखाओं में उपयोग किया जाता है। कोड उदाहरण:
<?php namespace Application\HelloBundle\Controller; use Symfony\Framework\WebBundle\Controller; class HelloController extends Controller { public function indexAction($name) { $author = new \Application\HelloBundle\Model\Author(); $author->setFirstName($name); $author->save(); return $this->render('HelloBundle:Hello:index', array('name' => $name, 'author' => $author)); } }
ऑटोलॉड के कारण यहां भी आवश्यकता नहीं है। Autoloader Symfony / Framework / WebBundle / Controller.php फ़ाइल में Symfony \ Framework \ WebBundle \ Controller वर्ग के लिए खोज करता है।
सब कुछ अच्छा है, हर कोई खुश है। निर्भरता स्पष्ट है और वर्ग प्रतिस्थापन आसान है:
<?php namespace Application\HelloBundle\Controller;
सभी सुविधाओं का अंत।
पिछले उदाहरण में उपयोग करना क्या आपको कुछ नहीं याद दिलाता है? यह बहुत अच्छा है पुराने पुराने आवश्यकता / requirement_once, है ना?
<?php
नेमस्पेस द्वारा शुरू की गई क्रियाशीलता मुख्य रूप से स्टार्टअप के उपयोग में आसानी को कम करती है। लेकिन समस्या केवल यह नहीं है कि आपको अधिक कोड लिखने की आवश्यकता है, स्वत: पूर्णता के साथ आईडीई आपको इसमें मदद कर सकता है, लेकिन इसके लिए आपको उन कक्षाओं का पूरा नाम जानना होगा जिनकी आपको आवश्यकता है। इनका उपयोग करने के लिए आपको फ्रेमवर्क कक्षाओं को अच्छी तरह से जानना चाहिए। यह "पहली पीढ़ी" स्टार्टअप से एक कदम पीछे है, जहां यह वर्ग नाम जानने के लिए पर्याप्त था।
और कोई उपाय नहीं है।
सच है, उनकी फ़ाइल संरचना को जाने बिना आधुनिक पुस्तकालयों का उपयोग करना बहुत अच्छा होगा? क्या होगा यदि आप इस तरह एक नियंत्रक लिख सकते हैं:
<?php class HelloController extends Controller { public function indexAction($name) { $author = new Author(); $author->setFirstName($name); $author->save(); return $this->render('HelloBundle:Hello:index', array('name' => $name, 'author' => $author)); } }
एक स्मार्ट ऑटोलोडर कंट्रोलर क्लास कॉल को इंटरसेप्ट करेगा, सिम्फनी / फ्रेमवर्क / वेबबंडल / कंट्रोलर.फैप फाइल को लोड करेगा और डायनामिक रूप से सिम्फनी \ फ्रेमवर्क \ वेबबंडल \ कंट्रोलर से कंट्रोलर के लिए एक उपनाम बनाएगा। दुर्भाग्य से PHP में, उपयोग संकलन समय पर एक उपनाम बनाता है, इसलिए यह कदम काम नहीं करेगा। बेशक यह eval का उपयोग करने का अवसर है, लेकिन यह संभवतः मैन्युअल रूप से फ़ाइलों को संलग्न करने से भी बदतर है। उदाहरण के लिए, आलसी लोडिंग के साथ संघर्ष और वर्ग नामों के टकराव के कारण फ्रेमवर्क के साथ काम करना संभव नहीं है।
सिम्फनी \ फ्रेमवर्क \ WebBundle \ Command
और
Symfony \ Components \ Console \ Command \ Command
जब तक फ्रेमवर्क के लेखक स्टार्टअप के बारे में अपना दृष्टिकोण नहीं बदलते, तब तक PHP का भविष्य मेरे लिए क्रियात्मक लगता है।
समस्या का समाधान।
व्यक्तिगत रूप से, मुझे लगता है कि क्रियाशीलता विकास को धीमा कर देती है। उदाहरण के लिए, माइक्रोफ़्रेम्स लें - वे न्यूनतम MVC पृथक्करण के साथ, अनुरोध को जल्दी से संसाधित करना संभव बनाते हैं। स्लिम (ऑटोलैड विदाउट नेमस्पेस) और सिलेक्स (नेमस्पेस के साथ ऑटोलैड) का उपयोग करते हुए लिखे गए एक उदाहरण के कोड की तुलना करें:
<?php
दूसरे उदाहरण में, ऑटोलॉड केवल चीजों को अधिक जटिल बनाता है।
आधुनिक रूपरेखा के डेवलपर्स बताते हैं कि वर्बोसिटी वह मूल्य है जो हम कोड की गुणवत्ता के लिए भुगतान करते हैं। मुझे यकीन नहीं है कि मैं इस कीमत का भुगतान करना चाहता हूं। मैं यह नहीं देखना चाहता कि PHP जावा में कैसे बदल जाता है, जहां कंप्यूटर विज्ञान के संदर्भ में कोड उत्कृष्ट है, लेकिन लिखने के लिए बहुत महंगा है। यह अन्य भाषाओं का उपयोग करने की इच्छा को प्रोत्साहित करता है, जहां नेमस्पेस के साथ स्टार्टअप का मुद्दा इसके लायक नहीं है, और एक ही समय में, त्वरित विकास संभव है।
उदाहरण के लिए रूबी को लें। सिनात्रा के रूप में एक ऐसी रूपरेखा है, जिसके उपयोग से हैलोवर्ल्ड एप्लिकेशन बहुत संक्षिप्त हो जाता है:
require 'sinatra' require 'erb' get '/hello/:name' do |name| @name = name erb :hello end
ओह, देखो, आवश्यकता का उपयोग यहां किया जाता है! और एक ही समय में, सब कुछ बहुत जल्दी और आसानी से लिखा जाता है।