👩🏻‍🔧 🧕🏻 🚾 स्थिर वर्ग के सदस्य। उन्हें अपने कोड को बर्बाद न करने दें 🚴🏿 ✍🏼 💪🏻

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

"क्लास-ओरिएंटेड प्रोग्रामिंग" तब होता है जब कक्षाओं का उपयोग किया जाता है जिसमें केवल स्थिर तरीके और गुण होते हैं, और क्लास का एक उदाहरण कभी नहीं बनता है। इस लेख में, मैं कहूंगा कि:

यह प्रक्रियात्मक प्रोग्रामिंग पर कोई लाभ नहीं है
वस्तुओं को मना मत करो
स्थिर वर्ग के सदस्यों की उपस्थिति! = मृत्यु परीक्षण

यद्यपि यह आलेख PHP के बारे में है, अवधारणा अन्य भाषाओं पर लागू होती है।

पर निर्भर करता है

आमतौर पर, कोड दूसरे कोड पर निर्भर करता है। उदाहरण के लिए:

$foo = substr($bar, 42);

यह कोड $bar चर और substr फ़ंक्शन पर निर्भर करता है। $bar सिर्फ एक स्थानीय चर है, उसी फ़ाइल में और उसी दायरे में थोड़ा अधिक परिभाषित किया गया है। substr एक PHP कोर फ़ंक्शन है। यहां सब कुछ सरल है।

अब, एक उदाहरण:

 $foo = normalizer_normalize($bar);

normalizer_normalize एक Intl पैकेज सुविधा है जिसे 5.3 संस्करण के बाद से PHP के साथ एकीकृत किया गया है और पुराने संस्करणों के लिए अलग से स्थापित किया जा सकता है। यहां यह पहले से ही थोड़ा अधिक जटिल है - कोड का प्रदर्शन किसी विशेष पैकेज की उपलब्धता पर निर्भर करता है।

अब, यह विकल्प:

 class Foo { public static function bar() { return Database::fetchAll("SELECT * FROM `foo` WHERE `bar` = 'baz'"); } }

यह कक्षा-उन्मुख प्रोग्रामिंग का एक विशिष्ट उदाहरण है। Foo Database से जुड़ा हुआ है। और हम यह भी मानते हैं कि Database वर्ग पहले से ही शुरू हो चुका है और डेटाबेस (डीबी) से कनेक्शन पहले ही स्थापित हो चुका है। संभवतः इस कोड का उपयोग किया जाएगा:

 Database::connect('localhost', 'user', 'password'); $bar = Foo::bar();

Foo::bar स्पष्ट रूप से Database और इसकी आंतरिक स्थिति की उपलब्धता पर निर्भर करता है। आप Database बिना Foo उपयोग नहीं कर सकते हैं, और Database को डेटाबेस कनेक्शन की आवश्यकता होती है। आप यह कैसे सुनिश्चित कर सकते हैं कि जब Database::fetchAll तो डेटाबेस कनेक्शन पहले से ही स्थापित Database::fetchAll ? एक तरह से इस प्रकार है:

 class Database { protected static $connection; public static function connect() { if (!self::$connection) { $credentials = include 'config/database.php'; self::$connection = some_database_adapter($credentials['host'], $credentials['user'], $credentials['password']); } } public static function fetchAll($query) { self::connect(); //  self::$connection... // here be dragons... return $data; } } '; class Database { protected static $connection; public static function connect() { if (!self::$connection) { $credentials = include 'config/database.php'; self::$connection = some_database_adapter($credentials['host'], $credentials['user'], $credentials['password']); } } public static function fetchAll($query) { self::connect(); //  self::$connection... // here be dragons... return $data; } }

Database::fetchAll कॉल करते Database::fetchAll , हम connect विधि को कॉल करके कनेक्शन के अस्तित्व की जांच करते हैं, जो कि यदि आवश्यक हो, तो कॉन्फ़िगरेशन से कनेक्शन पैरामीटर प्राप्त करता है। इसका मतलब है कि Database फ़ाइल पर निर्भर करता है config/database.php । यदि यह फ़ाइल मौजूद नहीं है, तो यह कार्य नहीं कर सकता है। हम और आगे जा रहे हैं। Database वर्ग एक डेटाबेस से बँधा होता है। यदि आपको अन्य कनेक्शन मापदंडों को स्थानांतरित करने की आवश्यकता है, तो यह कम से कम आसान नहीं होगा। कॉम बढ़ जाती है। Foo न केवल Database की उपलब्धता पर निर्भर करता है, बल्कि इसकी स्थिति पर भी निर्भर करता है। Database एक विशिष्ट फ़ोल्डर में एक विशिष्ट फ़ाइल पर निर्भर करता है। यानी संक्षेप में, Foo वर्ग फ़ोल्डर में फ़ाइल पर निर्भर करता है, हालांकि इसका कोड यह नहीं दिखाता है। इसके अलावा, वैश्विक राज्य पर बहुत अधिक निर्भरताएं हैं। प्रत्येक टुकड़ा दूसरे टुकड़े पर निर्भर करता है, जो सही स्थिति में होना चाहिए और कहीं भी यह स्पष्ट रूप से इंगित नहीं किया गया है।

कुछ परिचित ...

क्या यह एक प्रक्रियात्मक दृष्टिकोण की तरह लगता है? आइए एक प्रक्रियात्मक शैली में इस उदाहरण को फिर से लिखने का प्रयास करें:

 function database_connect() { global $database_connection; if (!$database_connection) { $credentials = include 'config/database.php'; $database_connection = some_database_adapter($credentials['host'], $credentials['user'], $credentials['password']); } } function database_fetch_all($query) { global $database_connection; database_connect(); //  $database_connection... // ... return $data; } function foo_bar() { return database_fetch_all("SELECT * FROM `foo` WHERE `bar` = 'baz'"); } 'होस्ट'], $ साख [ 'उपयोगकर्ता'], $ साख [ 'पासवर्ड']); function database_connect() { global $database_connection; if (!$database_connection) { $credentials = include 'config/database.php'; $database_connection = some_database_adapter($credentials['host'], $credentials['user'], $credentials['password']); } } function database_fetch_all($query) { global $database_connection; database_connect(); //  $database_connection... // ... return $data; } function foo_bar() { return database_fetch_all("SELECT * FROM `foo` WHERE `bar` = 'baz'"); }

जानें 10 अंतर ...
संकेत: एकमात्र अंतर Database::$connection की दृश्यता Database::$connection और $database_connection ।

कक्षा-उन्मुख उदाहरण में, कनेक्शन केवल Database वर्ग के लिए ही उपलब्ध है, और प्रक्रियात्मक कोड में यह चर वैश्विक है। कोड एक ही निर्भरता, संचार की समस्याओं की है, और एक ही तरह से काम करता है। $database_connection और Database::$connection बीच व्यावहारिक रूप से कोई अंतर नहीं है - यह एक ही चीज़ के लिए बस एक अलग वाक्यविन्यास है, दोनों चर में एक वैश्विक स्थिति है। क्लास नेमस्पेस का उपयोग करना थोड़ा मुश्किल है, बेशक, यह कुछ भी नहीं से बेहतर है, लेकिन यह कुछ भी गंभीरता से नहीं बदलता है।

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

इग्निशन कुंजी चालू करें

अब, OOP का प्रयास करते हैं। आइए Foo के कार्यान्वयन के साथ शुरू करें:

 class Foo { protected $database; public function __construct(Database $database) { $this->database = $database; } public function bar() { return $this->database->fetchAll("SELECT * FROM `foo` WHERE `bar` = 'baz'"); } }

अब Foo एक विशिष्ट Database पर निर्भर नहीं है। Foo का एक उदाहरण बनाते समय, आपको कुछ ऑब्जेक्ट को पारित करने की आवश्यकता होती है जिसमें Database की विशेषताएं होती हैं। यह Database या उसके वंशज का एक उदाहरण हो सकता है। इसलिए हम Database एक और कार्यान्वयन का उपयोग कर सकते हैं, जो कहीं और से डेटा प्राप्त कर सकता है। या कैशिंग लेयर है। या परीक्षणों के लिए एक स्टब है, और वास्तविक डेटाबेस कनेक्शन नहीं है। अब हमें Database का एक उदाहरण बनाने की आवश्यकता है, जिसका अर्थ है कि हम अलग-अलग मापदंडों के साथ कई अलग-अलग डेटाबेसों का उपयोग कर सकते हैं। आइए Database लागू करें:

 class Database { protected $connection; public function __construct($host, $user, $password) { $this->connection = some_database_adapter($host, $user, $password); if (!$this->connection) { throw new Exception("Couldn't connect to database"); } } public function fetchAll($query) { //  $this->connection ... // ... return $data; } }

ध्यान दें कि कार्यान्वयन कितना आसान हो गया है। Database::fetchAll कनेक्शन स्थिति की जांच करने की आवश्यकता नहीं है। Database::fetchAll को कॉल करने के लिए, आपको क्लास को तत्काल करने की आवश्यकता है। कक्षा का एक उदाहरण बनाने के लिए, आपको कनेक्शन पैरामीटर को कंस्ट्रक्टर के पास करना होगा। यदि कनेक्शन पैरामीटर मान्य नहीं हैं या कनेक्शन अन्य कारणों से स्थापित नहीं किया जा सकता है, तो एक अपवाद फेंक दिया जाएगा और ऑब्जेक्ट नहीं बनाया जाएगा। इसका मतलब यह है कि जब आप Database::fetchAll , तो आपको डेटाबेस कनेक्शन की गारंटी दी जाती है। इसका मतलब यह है कि Foo केवल कंस्ट्रक्टर में इंगित करना होगा कि उसे Database $database आवश्यकता है और इसका Database $database कनेक्शन होगा।

की एक प्रति के बिना Foo , आप कॉल नहीं कर सकते Foo::bar । Database उदाहरण के बिना, आप Foo उदाहरण नहीं बना सकते। मान्य कनेक्शन मापदंडों के बिना, आप Database का एक उदाहरण नहीं बना सकते।

आप बस अगर कम से कम एक शर्त संतुष्ट नहीं है, कोड का उपयोग करने में सक्षम नहीं होगा।

इसकी तुलना क्लास-ओरिएंटेड कोड से करें: आप किसी भी समय Foo::bar को कॉल कर सकते हैं, लेकिन अगर Database क्लास तैयार नहीं होता है तो एक त्रुटि होगी। Database::fetchAll किसी भी समय Database::fetchAll को कॉल कर सकते हैं, लेकिन एक त्रुटि तब होगी जब config/database.php फ़ाइल के साथ समस्याएं हैं। Database::connect वैश्विक स्थिति को सेट करता है जिस पर अन्य सभी ऑपरेशन निर्भर करते हैं, लेकिन यह निर्भरता की गारंटी नहीं है।

इंजेक्शन

कोड का उपयोग करता है से इसे आइए नज़र Foo । प्रक्रियात्मक उदाहरण:

 $bar = foo_bar();

आप इस लाइन को कहीं भी लिख सकते हैं और इसे निष्पादित किया जाएगा। इसका व्यवहार डेटाबेस से कनेक्शन की वैश्विक स्थिति पर निर्भर करता है। हालांकि कोड से यह स्पष्ट नहीं है। त्रुटि हैंडलिंग जोड़ें:

 $bar = foo_bar(); if (!$bar) { // -    $bar,  ! } else { //  ,   }

foo_bar की अंतर्निहित निर्भरता के foo_bar , त्रुटि के मामले में यह समझना मुश्किल होगा कि वास्तव में क्या टूट गया।

तुलना के लिए, यहाँ एक वर्ग-उन्मुख कार्यान्वयन है:

 $bar = Foo::bar(); if (!$bar) { // -    $bar,  ! } else { //  ,   }

कोई फर्क नहीं। त्रुटि हैंडलिंग समान है, अर्थात समस्याओं का स्रोत ढूंढना भी कठिन है। यह सब इसलिए है क्योंकि एक स्थैतिक विधि के लिए एक कॉल सिर्फ एक फ़ंक्शन कॉल है जो किसी अन्य फ़ंक्शन कॉल से अलग नहीं है।

अब OOP:

 $foo = new Foo; $bar = $foo->bar();

पीएचपी एक गंभीर त्रुटि से गिर जाएगी जब यह करने के लिए आता new Foo । हम चाहते हैं कि ने बताया Foo की एक प्रति की जरूरत है Database , लेकिन यह पारित नहीं किया।

 $db = new Database; $foo = new Foo($db); $bar = $foo->bar();

PHP फिर से गिर जाएगी क्योंकि हमने डेटाबेस कनेक्शन मापदंडों को पारित नहीं किया है जो हमने Database::__construct में निर्दिष्ट किया है।

 $db = new Database('localhost', 'user', 'password'); $foo = new Foo($db); $bar = $foo->bar();

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

लेकिन आइए कल्पना करें कि डेटाबेस से कनेक्ट करने के लिए पैरामीटर गलत हैं या हमें डेटाबेस के साथ कुछ समस्याएं हैं और कनेक्शन स्थापित नहीं किया जा सकता है। इस मामले में, new Database(...) को निष्पादित करते समय एक अपवाद फेंक दिया जाएगा। निम्न पंक्तियाँ बस विफल हो जाएंगी। इसलिए हमें $foo->bar() कॉल के बाद त्रुटि की जांच नहीं करनी है (बेशक, आप जांच सकते हैं कि आपके पास क्या लौट आया है)। यदि किसी पर निर्भरता के साथ कुछ गलत होता है, तो कोड निष्पादित नहीं किया जाएगा। और फेंके गए अपवाद में डीबगिंग के लिए उपयोगी जानकारी होगी।

एक वस्तु-उन्मुख दृष्टिकोण अधिक जटिल लग सकता है। प्रक्रियात्मक या वर्ग-उन्मुख कोड के हमारे उदाहरण में, केवल एक पंक्ति है जो foo_bar या Foo::bar कॉल foo_bar , जबकि ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण तीन लाइनें लेता है। सार को समझना महत्वपूर्ण है। हमने डेटाबेस को प्रक्रियात्मक कोड में आरंभीकृत नहीं किया है, हालांकि हमें इसे वैसे भी करने की आवश्यकता है। एक प्रक्रियात्मक दृष्टिकोण को तथ्य के बाद और प्रक्रिया में हर बिंदु पर त्रुटि प्रसंस्करण की आवश्यकता होती है। त्रुटि से निपटने के बाद से बहुत भ्रमित है मुश्किल ट्रैक करने के लिए जो निहित निर्भरता की त्रुटि के कारण। हार्डकोड निर्भरता को छुपाता है। त्रुटि के स्रोत स्पष्ट नहीं हैं। यह क्या यह अपने सामान्य कामकाज के लिए अपने कोड पर निर्भर करता है स्पष्ट नहीं है।

वस्तु-उन्मुख दृष्टिकोण सभी निर्भरता को स्पष्ट और स्पष्ट करता है। Foo को एक Database इंस्टेंस की आवश्यकता होती है, और एक Database इंस्टेंस को कनेक्शन मापदंडों की आवश्यकता होती है।

एक प्रक्रियात्मक दृष्टिकोण में, जिम्मेदारी कार्यों के साथ टिकी हुई है। हम Foo::bar विधि कहते हैं - अब इसे हमारे पास वापस करना चाहिए। इस विधि, बारी में, का कार्य प्रत्यायोजित की Database::fetchAll । अब सारी जिम्मेदारी उस पर है और वह डेटाबेस से जुड़ने और कुछ डेटा वापस करने की कोशिश कर रहा है। और अगर किसी भी बिंदु पर कुछ गलत हो जाता है ... कौन जानता है कि आपके पास क्या आएगा और कहां।

ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण कॉलिंग कोड के लिए जिम्मेदारी का हिस्सा बदल देता है, और यह इसकी ताकत है। Foo::bar को कॉल करना चाहते हैं? ठीक है, तो इसे डेटाबेस के लिए एक कनेक्शन दें। क्या कनेक्शन? इससे कोई फर्क नहीं पड़ता कि यह Database का एक उदाहरण था। यह निर्भरता इंजेक्शन की शक्ति है। यह आवश्यक निर्भरता को स्पष्ट करता है।

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

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

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

स्थैतिक सदस्य

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

 class Database { protected static $types = array( 'int' => array('internalType' => 'Integer', 'precision' => 0, ...), 'string' => array('internalType' => 'String', 'encoding' => 'utf-8', ...), ... ) }

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

स्थैतिक गुण कुछ डेटा को कैश करने के लिए भी उपयोगी हो सकते हैं जो सभी उदाहरणों के लिए समान हैं। स्थैतिक गुण मौजूद हैं, अधिकांश भाग के लिए, अनुकूलन तकनीक के रूप में, उन्हें एक प्रोग्रामिंग दर्शन के रूप में नहीं माना जाना चाहिए। और सहायक विधियाँ सहायक विधियाँ और वैकल्पिक निर्माणकर्ता के रूप में उपयोगी हैं।

स्थिर तरीकों के साथ समस्या यह है कि वे एक कठिन निर्भरता पैदा करते हैं। जब आप Foo::bar() , तो कोड की यह रेखा एक विशेष Foo वर्ग के साथ जुड़ जाती है। इस समस्याओं को जन्म दे सकता है।

निम्नलिखित परिस्थितियों में स्थिर विधियों का उपयोग स्वीकार्य है:

निर्भरता अस्तित्व की गारंटी है। मामले में कॉल आंतरिक है या निर्भरता पर्यावरण का हिस्सा है। उदाहरण के लिए:
```
 class Database { ... public function __construct($host, $user, $password) { $this->connection = new PDO(...); } ... } 
```
यहाँ Database एक विशिष्ट वर्ग - PDO पर निर्भर करता है। लेकिन PDO मंच का हिस्सा है, यह PHP द्वारा प्रदान किया गया एक डेटाबेस वर्ग है। किसी भी स्थिति में, आपको डेटाबेस के साथ काम करने के लिए कुछ प्रकार के एपीआई का उपयोग करना होगा।
आंतरिक उपयोग के लिए विधि। ब्लूम फ़िल्टर के कार्यान्वयन से एक उदाहरण:
```
 class BloomFilter { ... public function __construct($m, $k) { ... } public static function getK($m, $n) { return ceil(($m / $n) * log(2)); } ... } 
```
यह थोड़ा सहायक कार्य बस एक विशेष एल्गोरिथ्म के लिए एक आवरण प्रदान करता है जो निर्माणकर्ता में उपयोग किए गए $k तर्क के लिए एक अच्छी संख्या की गणना करने में मदद करता है। क्योंकि क्लास को तुरंत करने से पहले इसे कॉल किया जाना चाहिए, यह स्थिर होना चाहिए। इस एल्गोरिथ्म में कोई बाहरी निर्भरता नहीं है और इसे प्रतिस्थापित करने की संभावना नहीं है। यह इस प्रकार है के रूप में प्रयोग किया जाता है:
```
 $m = 10000; $n = 2000; $b = new BloomFilter($m, BloomFilter::getK($m, $n)); 
```
यह कोई अतिरिक्त निर्भरता नहीं बनाता है। वर्ग पर ही निर्भर करता है।
वैकल्पिक निर्माणकर्ता। एक अच्छा उदाहरण PHP में निर्मित DateTime वर्ग है। आप इसका एक उदाहरण दो अलग-अलग तरीकों से बना सकते हैं:
```
 $date = new DateTime('2012-11-04'); $date = DateTime::createFromFormat('dm-Y', '04-11-2012'); 
```
दोनों स्थितियों में, परिणाम DateTime का एक उदाहरण होगा DateTime और दोनों ही मामलों में कोड DateTime वर्ग के लिए एक तरह से या किसी अन्य के लिए बाध्य होता है। स्टैटिक DateTime::createFromFormat एक वैकल्पिक ऑब्जेक्ट DateTime::createFromFormat है जो new DateTime DateTime::createFromFormat के समान है, लेकिन अतिरिक्त कार्यक्षमता का उपयोग करके। तुम कहाँ एक लिख सकते हैं new Class , आप लिख सकते हैं और कर सकते हैं Class::method() कोई नई निर्भरता नहीं पैदा होती है।

स्थैतिक तरीकों का उपयोग करने के अन्य विकल्प बाध्यकारी को प्रभावित करते हैं और अंतर्निहित निर्भरता का निर्माण कर सकते हैं।

अमूर्त का वचन

व्यसनों के साथ यह सब क्यों उपद्रव? अमूर्त करने की क्षमता! आपके उत्पाद की वृद्धि के साथ, इसकी जटिलता बढ़ती है। और अमूर्तता जटिलता के प्रबंधन की कुंजी है।

उदाहरण के लिए, आपके पास एक Application वर्ग है जो आपके आवेदन का प्रतिनिधित्व करता है। यह वर्ग के साथ संचार User , जो प्रस्तुत करने के लिए एक सदस्य है। जो Database से डेटा प्राप्त करता है। Database वर्ग को एक DatabaseDriver आवश्यकता होती है। DatabaseDriver को कनेक्शन मापदंडों की आवश्यकता होती है। और इसी तरह। यदि आप बस Application::start() सांख्यिकीय रूप से कहते हैं, जो User::getData() सांख्यिकीय रूप से कॉल करेगा, जो DB को User::getData() रूप से कॉल करेगा, और इसी तरह, इस उम्मीद में कि प्रत्येक परत अपनी निर्भरता का पता User::getData() , तो आपको एक भयानक गड़बड़ मिल सकती है। ऐसा नहीं है। यह अनुमान करना असंभव है कि क्या Application::start() कॉल काम करेगा, क्योंकि यह बिल्कुल स्पष्ट नहीं है कि आंतरिक निर्भरता कैसे व्यवहार करेगी। इससे भी बदतर यह कि एक ही रास्ता के व्यवहार को प्रभावित करने के लिए है Application::start() - इस वर्ग के लिए स्रोत कोड और वर्ग कोड है कि वह वर्गों और कोड है कि उन वर्गों vyzyzvayut ... घर में है कि जैक बनाया vyzyzvaet संशोधित करने के लिए है।

जटिल एप्लिकेशन बनाते समय सबसे प्रभावी दृष्टिकोण अलग-अलग हिस्सों को बनाना है जो आप भविष्य में भरोसा कर सकते हैं। जिनमें से पार्ट्स सोच आप सुनिश्चित हो सकते हैं बंद कर सकते हैं। उदाहरण के लिए, जब स्थैतिक Database::fetchAll(...) , तो कोई गारंटी नहीं है कि डेटाबेस से कनेक्शन पहले से ही स्थापित है या स्थापित किया जाएगा।

 function (Database $database) { ... }

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

इन निर्भरताओं की निर्भरता और निर्भरता के बारे में सोचने की क्षमता के बिना, कम से कम किसी भी जटिल एप्लिकेशन को लिखना लगभग असंभव है। Database निर्भरता के एक समूह के साथ एक छोटा आवरण वर्ग या एक विशाल बहु-परत राक्षस हो सकता है, यह एक छोटे आवरण के रूप में शुरू हो सकता है और समय के साथ एक विशाल राक्षस में उत्परिवर्तित हो सकता है, आप Database वर्ग को प्राप्त कर सकते हैं और फ़ंक्शन के वंशज हो सकते हैं, यह आपके function (Database $database) लिए महत्वपूर्ण नहीं है function (Database $database) जब तक function (Database $database) का सार्वजनिक इंटरफ़ेस नहीं बदला जाता है। यदि आपकी कक्षाएं निर्भरता इंजेक्शन का उपयोग करके बाकी एप्लिकेशन से सही तरीके से अलग हो जाती हैं, तो आप उनमें से प्रत्येक का परीक्षण उनकी निर्भरता के बजाय स्टब्स का उपयोग करके कर सकते हैं। जब आपने यह सुनिश्चित करने के लिए कक्षा का परीक्षण किया हो कि यह काम करना चाहिए, तो आप अपने सिर से अतिरिक्त रूप से यह जानकर प्राप्त कर सकते हैं कि डेटाबेस के साथ काम करने के लिए आपको डेटाबेस उदाहरण का उपयोग करने की आवश्यकता है।

कक्षा-उन्मुख प्रोग्रामिंग बेवकूफ है। OOP का उपयोग करना सीखें।