मुझे लगता है कि OOP क्या है, इस लेख के ढांचे के भीतर, यह याद दिलाने के लिए कि यह बहुत ही अच्छा होगा, इसलिए मैं सीधे समस्याग्रस्त पर जाऊंगा।
डेवलपर्स जो अन्य प्रोग्रामिंग भाषाओं से PHP में आते हैं और PHP में मुठभेड़ कक्षाएं (यहां और उसके बाद PHP के रूप में संदर्भित) एक नुकसान में होगी कि उनका उपयोग कैसे किया जा सकता है। और यह सब इस तथ्य के कारण है कि PHP पर स्क्रिप्ट का जीवनकाल एप्लिकेशन सॉफ़्टवेयर की तुलना में बहुत छोटा है और केवल एक ही कार्य चक्र बनाता है, जबकि एप्लिकेशन सॉफ़्टवेयर बहुत लंबे समय तक अपने घटकों के साथ रह सकता है और बातचीत कर सकता है। नतीजतन, दुनिया एक कोड है जिसमें कक्षाएं केवल उन नामस्थानों को लागू करती हैं जो PHP में अनुपस्थित हैं ।
class A {
public static function b() {}
public static function c() {}
public static function d() {}
}
हां - यहां तक कि इस दृष्टिकोण के बहुत सारे फायदे हैं। उदाहरण के लिए, हम एक डेटा क्षेत्र से संबंधित कार्यों को एक रैपर वर्ग में अलग करने में सक्षम थे, जिससे कोड में फ़ंक्शन नामों के संघर्ष की संभावना कम हो गई, साथ ही साथ कोड व्यवहार्यता और कार्यों के व्यवहार की ट्रैकिंग अधिक पारदर्शी हो गई:
User::register($name, $pwd);
//... a lot of code ...
System::Log($message, $code);
इस उदाहरण से प्रत्येक पंक्ति स्वयं के लिए बोलती है और अतिरिक्त टिप्पणियों की आवश्यकता नहीं होती है, जो निस्संदेह एक प्लस है।
लेकिन आइए ओओपी को न केवल एक प्रोग्रामिंग प्रतिमान के रूप में देखें जो पहले से ही ऊब मूल सुविधाओं के साथ है: विरासत, एनकैप्सुलेशन और बहुरूपता, लेकिन इसे हमारे आसपास की दुनिया के रूप में देखें। वस्तुएं हमारे चारों ओर क्या कह रही हैं? उदाहरण के लिए मेरा चश्मा ले लो। उनके बारे में क्या कहा जा सकता है? आप उनके वजन और आकार, रंग और घनत्व को माप सकते हैं - ये वर्ग \ "चश्मा \" के गुण होंगे, लेकिन इसके द्वारा वे अभी भी लेंस से गुजरने वाले प्रकाश को तोड़ सकते हैं और अपवर्तित कर सकते हैं - और ये पहले से ही विधियां हैं। हमें चश्मे से चाय नहीं मिल सकती है, जैसे चश्मे की गति को मापना। ये कैसी बात कर रहा है? वर्ग \ "चश्मा \" में बातचीत के लिए एक निश्चित गुंजाइश और अवसर हैं। हम PHP में अपनी कक्षाओं के साथ भी ऐसा ही कर सकते हैं।
हालाँकि स्क्रिप्ट का जीवन चक्र केवल एक है, लेकिन इसे खूबसूरती से जीया जा सकता है! हम ऐसा करने की कोशिश करेंगे ...
कल्पना कीजिए कि हमारे पास एक सामाजिक नेटवर्क है (ठीक है, आज उनके बारे में क्या है? :)); इस सामाजिक नेटवर्क में उपयोगकर्ता हैं, और प्रत्येक उपयोगकर्ता का अपना ब्लॉग है। और अब चलो प्रस्तुत की गई संस्थाओं में से प्रत्येक के कार्यक्षेत्र को संक्षिप्त और सुरुचिपूर्ण ढंग से प्रदर्शित करने का प्रयास करें।
उपयोगकर्ता के पास गुणों का एक सेट है। इसे रहने दें: लॉगिन, पासवर्ड और ईमेल। उपयोगकर्ता कुछ क्रियाएं कर सकता है: लॉग इन करें, लॉग आउट करें, एक ब्लॉग बनाएं और उसे लिखें।
ब्लॉग, बदले में, निम्नलिखित गुण हैं: लेखक, विषय संग्रह और निर्माण तिथि। एक ब्लॉग अपने आप में एक पोस्ट जोड़ सकता है।
हम खुद को संस्थाओं के तरीकों और गुणों के इस सेट तक सीमित रखते हैं। कोड में ऐसी संरचना की कल्पना करने का सबसे सुरुचिपूर्ण तरीका क्या है? मैं निम्नलिखित विकल्प सुझाता हूं:
class Blog {
public $topics_list;
public $creation_date;
private $data; // ,
public function __construct($id) { //id
//- $this->data,
}
public function getAuthor() {
static $author; // , , , -
if (empty($author)) {
$author = new User($this->data[\'author_id\']);
}
return $author;
}
public function addTopic(Topic $topic) { ... } // .
}
class User { ... } // , ,
तो - हमने क्या हासिल किया है? इस तरह से दोनों वर्गों का निर्माण करने के परिणामस्वरूप, हमारे पास प्रत्येक वस्तु के लिए जिम्मेदारी के स्पष्ट क्षेत्र हैं, इसके अलावा, हम अनावश्यक मापदंडों को पारित करने के साथ घूमेंगे नहीं। उदाहरण के लिए, एक ब्लॉग प्रविष्टि बनाएँ "पुराने जमाने का रास्ता \" और वर्णित लेआउट के आधार पर।
पुराने ढंग से:
$user_id = $_SESSION[\'user_id\']; // id
$topic_message = \" \";
Blog::addTopic($user_id, $topic_message); //
सब कुछ स्पष्ट और स्वाभाविक लगता है, एक चीज को छोड़कर - जब किसी विषय को बनाने के लिए तर्क पारित करते हैं, तो उपयोगकर्ता की भूमिका स्पष्ट नहीं होती है। आइए देखें कि समान कोड नए दृष्टिकोण के साथ कैसा दिखेगा:
$user = new User($_SESSION[\'user_id\']);
$topic_message = \" \";
$user->getBlog()->addTopic($topic_message);
यहां ब्लॉग और उपयोगकर्ता के बीच का संबंध बहुत अधिक स्पष्ट है ... और अगर आपको लगता है कि विषय भी एक वस्तु है और इसमें संपत्ति \ "संदेश \" है, तो हम इसे इस तरह प्राप्त कर सकते हैं:
$user = new User($_SESSION[\'user_id\']);
echo $user->getBlog()->getTopics()->topic[$topic_id]->message;
इस तरह के छोटे उदाहरणों में, लाभ बहुत स्पष्ट नहीं हो सकता है, लेकिन जब कोड दसियों या हजारों संस्थाओं के संपर्क तंत्र में बढ़ता है, तो उनमें से प्रत्येक का तर्क अधिक पारदर्शी और स्पष्ट हो जाता है, जो कोड की सहायता, विस्तार, और पठनीयता को प्रभावित करता है। इतनी छोटी स्क्रिप्ट जीवन काल के लिए भी नहीं ...
यदि प्रश्न पढ़ने के बाद, मुझे उनका उत्तर देने में खुशी होगी।
PS मुझे बताएं कि हेबर पर विषयों में कोड के खंड कैसे बनाएं, लेकिन किसी तरह मैं इसे नहीं पढ़ सका :(