क्या ओओपी PHP में उपयोग करने लायक है?

Question

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग अच्छा है या नहीं, इस पर कई बहसें हैं। लेकिन, पीएचपी में ओओपी का उपयोग धीमा है। प्रक्रियात्मक प्रोग्रामिंग और तेज़ गति और धीमी गति से ओओपी का उपयोग करने के लिए यह एक अच्छा व्यापार होगा (क्योंकि प्रत्येक बार पेज लोड होने पर कक्षाएं शुरू की जानी चाहिए और बड़ी वेबसाइटें धीमी हो जाएंगी)।

अधिक महत्वपूर्ण बात यह है कि कक्षा के अंदर सामान लपेटना और स्थिर कार्यों का उपयोग करना अच्छा होगा या क्या यह उपसर्ग पूर्व के साथ कई झूठ बोलने के लिए बेहतर होगा: wp_function()।

Answer 1

हां, ओओपी का उपयोग करना लगभग हमेशा एक अच्छा विचार है। ऐसा इसलिए है क्योंकि ओओपी कोडिंग की एक शैली है, और अधिकांश भाग के लिए कोडिंग शैलियों को आसानी से भाषाओं में स्थानांतरित करने में सक्षम हैं।

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

नहीं, उन तक पहुंचने के लिए प्रक्रियात्मक कार्यों का उपयोग करना शायद एक अच्छा विचार नहीं है। ऐसा इसलिए है क्योंकि, आपको शायद राज्य को बनाए रखने के लिए ऐसा कुछ करना होगा।

function myFunc() 
{ 
    global $class; 
    $class->doMethod(); 
} 

function myFunc2() 
{ 
    global $class; 
    $class->doMethod2(); 
} 

यह एक बुरा विचार है क्योंकि यह वैश्विक स्थिति का एक टन बनाता है।

Answer 2

यदि आप PHP के साथ ओओ का उपयोग करने के बारे में चिंतित हैं, तो डर नहीं है: PHP चारों ओर एक धीमी भाषा है। यदि आप ऐसा कुछ कर रहे हैं जो ऑब्जेक्ट्स का उपयोग करने से गति हानि के लिए पर्याप्त प्रोसेसर-गहन है, तो आपको PHP का उपयोग नहीं करना चाहिए।

स्थिर कार्यों के संबंध में, यह एक डिज़ाइन विकल्प है, लेकिन मैं पूरी तरह स्थिर कार्यों से बने वर्गों से बचने के पक्ष में गलती करूंगा। उपसर्गों पर इसका कोई फायदा नहीं है, और केवल एक निर्माण का उपयोग करना क्योंकि यह एक अच्छा विचार नहीं है।

Answer 3

ओओपी के अपने गुणों की तुलना में अधिक योग्यता है। See PHP OOP, What Are The Benefits?। OOP vs PP in PHP के लिए भी देखें।

Answer 4

हाँ जैसे आपका आवेदन बढ़ता है .. (और यह होगा) यह आपको कई घंटों की निराशा बचाएगा। और खुद को दोहराएं (सभी जगहों पर चिपकने वाला कोड कॉपी करना) .. :)

Answer 5

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

Answer 6

मैं चाचा 102 के उत्तर से दृढ़ता से असहमत हूं।

इस प्रश्न का उचित उत्तर कई पुस्तकों को भर देगा - यहां 20 लाइन पोस्ट कभी भी ध्यान न दें।

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

ओओ बनाम प्रक्रियात्मक कोडिंग के लिए PHP की उपयुक्तता के संबंध में, निश्चित रूप से भाषा की जड़ें बाद में हैं (लेकिन ध्यान दें कि जावा और एएसपी दोनों वास्तविक ओओ भाषाओं की बजाय संकर हैं)।

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

का तर्क करने के लिए है कि आप हमेशा क्योंकि यह OO कोड की तुलना में तेजी से चलेगा प्रक्रियात्मक कोड लिखना चाहिए:

1) जरूरी सच 2 नहीं है) पूरी तरह से हार्डवेयर लागत बनाम डेवलपर समय के रिश्तेदार लागत पर ध्यान नहीं देता

यह एक वर्ग के अंदर सामान लपेट और स्थिर कार्यों

यह देखते हुए कि नामस्थान अब पीएचपी में उपलब्ध हैं उपयोग करने के लिए अच्छा होगा, यह एक वास्तव में गंदा तरीका नाम स्थान col से बचने के लिए है lisions और कुछ नहीं मैं सिफारिश करेंगे।

सी

Answer 7

प्रदर्शन के बारे में एक ही तर्क उद्देश्य C और C++ दिन में वापस के बारे में किए गए थे। और उस समस्या का उत्तर उपलब्ध स्मृति और प्रसंस्करण शक्ति का लाभ उठाना था जो लगातार, बेहतर और तेज़ हो रहा है।

हां, ओओ को चलाने के लिए और संसाधनों की आवश्यकता है। लेकिन ओओ का उपयोग करने के लाभ ओओ अनुप्रयोगों का समर्थन करने के लिए हार्डवेयर लागत $$ (जो महत्वहीन होने की संभावना है) से अधिक है।

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

ध्यान रखें कि भले ही PHP वहां सबसे तेज़ प्लेटफॉर्म न हो (जावा, उदाहरण के लिए, इसके बट को मारता है) PHP का उपयोग इंटरनेट पर कुछ सबसे अधिक ट्रैफिक भारी वेबसाइटों को करने के लिए किया जाता है: अर्थात् फेसबुक।

यदि आपको PHP और OO के बारे में कोई अन्य संदेह है, तो ज़ेंड और Magento (ज़ेंड पर आधारित) देखें। Magento एक बहुत संसाधन-गहन मंच है, स्मृति उपयोग प्रति उदाहरण 36 एमबी से ऊपर हो सकता है। हालांकि मंच स्वयं लाखों हिटों को संभालने में सक्षम है। ऐसा इसलिए है क्योंकि हार्डवेयर संसाधनों की स्वस्थ सेवा के साथ एक उचित रूप से कॉन्फ़िगर किया गया सर्वर वातावरण ओओ का उपयोग करने के सभी फायदे सर्वर की लागत को दूर करने के लिए करता है। लेकिन क्लस्टर कंप्यूटर की दुनिया में, प्रसंस्करण शक्ति और स्मृति (जिम्मेदारी से) आपके लिए उपलब्ध नहीं है - आईएमएचओ - नैदानिक ​​पागलपन।

Answer 8

वास्तव में कोई सही उत्तर नहीं है क्योंकि यह कई अज्ञात चर पर निर्भर करता है, और फिर यह सब कुछ या कुछ भी नहीं होना चाहिए।

उदाहरण के लिए, यदि आप अपने आवेदन को एमवीसी मॉडल में विभाजित करते हैं, तो हो सकता है कि आपका मॉडल ओओ हो, लेकिन नियंत्रक को अधिक सरल रूप से प्रक्रियात्मक रखें।

आप सामान्य स्थिर कार्यों को समूहबद्ध करने के साधनों के रूप में कक्षाओं का उपयोग कर सकते हैं, या आप इसे सक्रिय रिकॉर्ड पैटर्न में बहुत आगे ले जा सकते हैं।

यदि आप एक छोटे से सिंगल-पेज वेबफॉर्म का निर्माण कर रहे हैं जो किसी ईमेल में पोस्ट बंद करता है, तो आपको वास्तव में ओओ की आवश्यकता नहीं होती है - न कि शायद आप लीवरेज के लिए मौजूदा मेल क्लास शामिल कर सकते हैं।

कोई भी परियोजना जो आप ले रहे हैं उसे समझे बिना आपको उचित सलाह दे सकती है।

उस ने कहा, यदि आपकी एकमात्र चिंता गति है, तो ओओ थोड़ा धीमा हो जाएगा। और ओओ लाभों की नकल करने के लिए प्रक्रियात्मक PHP में भी बहुत सी चीजें हैं जो आप कर सकते हैं। लेकिन जब तक आप एक बड़ी परियोजना नहीं ले रहे हैं, तो अतिरिक्त ओवरहेड कभी भी ज्यादा नहीं होगा। और जब तक आपके पास एक बड़ी परियोजना है, ओओ के पेशेवर अपने ओवरहेड के विपक्ष से अधिक हो सकते हैं।

Answer 9

मैं इस बारे में उत्सुक था। दुर्भाग्य से जब मैंने अपना कोड प्रक्रियात्मक से ओओपी में बदल दिया, तो मैंने कुछ मानक चलाए और पहले से नहीं।

यहां बेंचमार्क कोड है।

class game{ 
    function maxp($val){ 
    return max(0,pow($val,0.5));   
    } 
} 

$game = new game; 

for($i=0;$i<100000;$i++){ 
    $game->maxp(100); 
    //game::maxp(100); 
} 

ओओपी परिणाम 0.13 और 0.2 सेकंड के बीच थे;

प्रक्रियात्मक परिणाम 0.08 और 0.1 सेकंड के बीच थे।

परिणाम एक अच्छी अवधि के अनुरूप बने रहे।

मैं आपको अपने स्वयं के परीक्षण चलाने के लिए प्रोत्साहित करता हूं।

PHP 5.4.3