ओओ या प्रक्रियात्मक PHP?

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

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

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

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

शायद "व्यापार वस्तुओं" का प्रतिनिधित्व करने के लिए वस्तुओं का उपयोग करके, कुछ प्रकार का संकर दृष्टिकोण सबसे अच्छा होगा, लेकिन पारंपरिक, प्रक्रियात्मक कोड का उपयोग करके HTML आदि को प्रस्तुत करना?

टिप्पणियों की बहुत सराहना की गई। - रॉल्फ

स्रोत

2010-07-16 Rolf

निश्चित रूप से ओओ के साथ जाएं। PHP 1 99 5 (डी) के बाद से एक लंबा सफर तय कर चुका है और अब यह प्रक्रियात्मक प्रक्रियाओं पर ओओ को प्रोत्साहित करता है। इसके अलावा, अधिकांश PHP प्रोग्रामर ओओ के साथ अच्छी तरह से जानते हैं (हालांकि आजकल PHP4 के आधार पर आपको विरासत PHP अनुप्रयोगों में बहुत से प्रक्रियात्मक कोड मिलेंगे)। वेबसाइटों और वेब अनुप्रयोगों को तेजी से विकसित करने के लिए मैं एक ढांचे का उपयोग करने की सलाह देता हूं। बहुत सारे परिपक्व मजबूत PHP ढांचे (ज़ेंड, सिम्फनी) हैं जो मूल रूप से डिजाइन पैटर्न (एमवीसी!) के बहुमत को लागू करते हैं ताकि यह आपको बहुत समय बचा सके। मेरा पसंदीदा ज़ेंड फ्रेमवर्क है लेकिन मुझे सिम्फनी भी पसंद है। वील को फिर से शुरू करने की कोई जरूरत नहीं है। –

सभी उत्तरों के लिए धन्यवाद दोस्तों! ऐसा लगता है कि ओओपी के साथ जाने के लिए जीनियल राय है, जो मेरे द्वारा ठीक है क्योंकि मैं एएसपी.Net से आ रहा हूं। मैं शायद मौजूदा ढांचे में से एक के माध्यम से संभवतः एमवीसी का उपयोग करूंगा। Php.MVC को बहुत देख रहे थे - किसी के पास इसका अनुभव है? – Rolf

उन लोगों के लिए अनुपूरक जो समान दुविधा हैं: मैंने ओओपी जाने का फैसला किया, और जीवन को थोड़ा आसान बनाने के लिए एक PHP-ढांचे का उपयोग किया।बहुत से शोध के बाद, मैंने अंततः ** वाईआई फ्रेमवर्क ** ([लिंक] (http://www.yiiframework.com) के साथ जाने का फैसला किया), क्योंकि यह सबसे अधिक "पूरी तरह से ओओपी" PHP ढांचे में से एक प्रतीत होता है वहाँ से बाहर। – Rolf

लेकिन यह महत्वपूर्ण है कि प्रोग्रामर के लिए एक प्रोग्रामर के लिए कोड को समझने में काफी आसान है।

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

मुझे लगता है कि अधिकांश PHP प्रोग्रामर ओओ-कोड में उपयोग नहीं किए जाते हैं, तो शायद यह प्रक्रियात्मक कोड के पक्ष में एक बिंदु है?

मुझे शक है। मैं कई सम्मेलनों में गया हूं और ओओपी के साथ कोई समस्या नहीं है। वास्तव में, मैंने प्रक्रियात्मक कोड की एक पंक्ति भी नहीं देखी। इसके अलावा, सभी प्रमुख ढांचे पूर्ण ओओपी हैं। आपको मुख्य रूप से PHP4 अनुप्रयोगों में और रूकी कोड को देखते समय प्रक्रियात्मक प्रतिमान मिलेगा।

लेकिन अपने प्रश्न का उत्तर देने के लिए: यदि आप और आपके डेवलपर आरामदायक हैं तो मैं ओओ का उपयोग कहूंगा।निजी तौर पर, मुझे व्यू भाग में प्रक्रियात्मक कोड एक बुरा विचार मिलता है, क्योंकि आप पूरी तरह से अनजान टेम्पलेट्स के लिए इंटरमीलिंग लॉजिक और प्रस्तुति कोड समाप्त कर सकते हैं। कुछ और रखरखाव दृष्टिकोण के लिए POEAA's Web Presentation Patterns देखें।

यदि आप इसे बहुत अधिक महसूस करते हैं तो आपको एमवीसी का उपयोग करने की आवश्यकता नहीं है। यदि आप चाहें तो पेज कंट्रोलर का प्रयोग करें। लेकिन फिर, एमवीसी संकेत है कि या तो लागू करने के लिए कठिन है और वहां plenty frameworks है जो आपके काम से दूर रह जाएगा।

स्रोत

2010-07-16 07:21:05 Gordon

अच्छी तरह से रखो, मैं उद्धरण रखूंगा "कोड की पठनीयता प्रोग्रामिंग प्रतिमान से बंधी नहीं है बल्कि कोड कैसे लिखा गया है।" – Anax

'मैं कई सम्मेलनों में गया हूं और ओओपी के साथ कोई समस्या नहीं है, मुझे विश्वास नहीं है कि कॉन्फ़्रेंस गोबर औसत PHP प्रोग्रामर का प्रतिनिधित्व करते हैं। क्या कॉन्फ्रेंसर्स अधिक जानकार होने की संभावना नहीं रखते हैं? – Znarkus

@Znarkus वक्ताओं निश्चित रूप से, लेकिन उपस्थित लोगों? अनुमोदित, हर पेशेवर डेवलपर सम्मेलन में भाग नहीं लेता है, लेकिन यदि वे व्यवसाय में रहना चाहते हैं, तो उन्हें नवीनतम विकास के साथ रहना होगा। और जब से PHP5 के बाद से ओओपी सीखना था। जैसे मैंने कहा, बस वहां प्रमुख PHP परियोजनाओं को देखें। बहुत गंभीर नहीं हैं (ठीक है, वर्डप्रेस शायद) जो ओओपी को पूरी तरह से गले लगाता नहीं है। – Gordon

यह सब आपके लक्ष्य पर निर्भर करता है।

यदि आप प्रक्रियात्मक दृष्टिकोण पर बाद में अपनी परियोजना का विस्तार नहीं करना चाहते हैं तो ठीक है।
यदि आप पूर्वनिर्धारित वस्तुओं का उपयोग करके अपने कोड का तेजी से हिस्सा विकसित करने में सक्षम हैं तो यह तरीका है।
यदि आप अपने कोड को नीचे से नीचे तक लिख सकते हैं तो बिना किसी प्रयास के "प्रक्रियात्मक" ठीक है।

स्रोत

2010-07-16 07:07:03 Thariama

मैं निश्चित रूप से ओओ दृष्टिकोण के साथ जाऊंगा।

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

न केवल रखरखाव बढ़ता है, बल्कि इस तरह आप विकास के समय में भी कटौती करते हैं, जिस तरह से मैं इसे देखता हूं यह जीत-जीत की स्थिति है!

स्रोत

2010-07-16 07:07:11

न तो सिद्धांत, न ही केक विशेष रूप से हल्के वजन – Gordon

@ गॉर्डन: बहस योग्य हो सकता है, लेकिन मैं सिद्धांत को भारी वजन नहीं मानूंगा (जैसा कि ज़ेडएफ जैसे पूर्ण फ्रेम वाले ढांचे की तुलना में)। –

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

निष्पक्ष होने के लिए PHP में बनाए गए किसी भी और वेबसाइट को ओओ-वे में बनाया जाना चाहिए। जैसा कि आपने .NET और Java को भी प्रोग्राम किया है, आपको पता होना चाहिए कि ओओ में कोडिंग कोड को बनाए रखने योग्य बनाता है। साथ ही, यदि आप कभी भी PHP का उपयोग करके और अधिक वेबसाइट बनाने की योजना बनाते हैं तो यह अच्छा अभ्यास है।

स्रोत

2010-07-16 07:08:06 Tjirp

मैं काफी सरल साइट के लिए स्क्रैच से लिखित कोड पर WordPress की सिफारिश करना चाहता हूं।

डब्ल्यूपी को कस्टमाइज़ करने के तरीके के बारे में जानने के लिए आपको वेबस्पेस और कम समय की आवश्यकता है। बाहर showcase

आप अभी भी खरोंच से लिखने के लिए .. जानना चाहते हैं

चेक इसकी बेहतर OO पालन करने के लिए, आप

स्रोत

2010-07-16 07:10:26 CoderHawk

+1! –

निजी तौर पर Zend या Kohana

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

OOP के प्रमुख लाभ मैं PHP के लिए यह देखने के रूप में है कि यह MVC (या समान) की तरह दोनों काफी साफ कोडिंग शैलियों प्रोत्साहित करती है और सामान्य कार्यों के लिए & निर्माण पुस्तकालयों का उपयोग करने के लिए प्रोत्साहित करती है कोडर , बहुत कम समय में समाधान को बनाए रखना और कम अनदेखा बग के साथ संभवतः।

स्रोत

2010-07-16 07:13:29 46bit

हालांकि मुझे गलत मत समझो - मैं यह नहीं कह रहा हूं कि ओओपी का उपयोग PHP में किए गए हर साइट के लिए किया जाना चाहिए, बहुत छोटी साइटों के साथ यह पूरी तरह खत्म हो जाती है जब तक कि आप केवल पुस्तकालयों का एक समूह जोड़ रहे हों (जो उस मामले में अभी भी प्रक्रियात्मक कोड के साथ सबसे अच्छा किया जाना चाहिए)। – 46bit

PHP लिखते समय स्वीकार करने वाली पहली बात यह है कि यह मुख्य रूप से एक templating भाषा है। दस्तावेज गतिशील बिट्स बनाने के लिए PHP को HTML दस्तावेज़ में रखा जाना है।

PHP ओओ डिज़ाइन को कार्यान्वित करने में सक्षम है, लेकिन आपके द्वारा लिखे गए कोड लगभग सी # कोड (और संभवतः जावा, लेकिन मुझे टिप्पणी करने के लिए जावा नहीं पता) के रूप में उतना ही अच्छा नहीं होगा।

आप कहते हैं कि आपके पास लेख बनाने के लिए एक इंटरफ़ेस होगा - जो यहां या वहां थोड़ा गतिशील सामग्री जोड़ने से अधिक जटिल लगता है। यह ओओ उपचार से लाभ हो सकता है।

दूसरी ओर, कई PHP सीएमएस हैं जो पहले से ही बनाए गए हैं, जैसे कि wordpress, Drupal और Joomla!, जो आपकी आवश्यकताओं को बॉक्स से बाहर कर सकते हैं।

निष्कर्ष में - यदि एक पूर्व-निर्मित समाधान आपके अनुरूप नहीं है, तो ओओ रूट को कुछ प्रक्रियात्मक स्क्रिप्ट के साथ सभी को एक साथ जोड़ने के लिए जाएं।

स्रोत

2010-07-16 07:20:46

असल में, इस परियोजना का पूरा कारण वर्तमान जूमला-आधारित साइट को प्रतिस्थापित करना है, जिसे संगठन की आवश्यकताओं के अनुकूल बनाने के लिए बहुत बोझिल माना गया है। तो हम मौजूदा सीएमएस के साथ नहीं जा रहे हैं। – Rolf

-1

मैं ओओपी के साथ जाऊंगा। यह आसान होगा और यदि आपको कुछ मौका मिलता है तो आपको कम कोड फिर से लिखना होगा :)

स्रोत

2010-07-16 07:28:56 aniri

यदि यह एक साधारण वेबसाइट है, और सामग्री उसमें बहुत कुछ नहीं बदलेगी, तो मैं प्रक्रियात्मक कोड का उपयोग कर किसी पर फेंक नहीं पाऊंगा एक पूर्ण, वस्तु-उन्मुख समाधान लिखने पर (जो अधिक हो सकता है)। उदाहरण के लिए:

<?php 
switch ($_GET['filename']) { 
    case "news": 
     require_once('inc/news.php');  // your news functions 
     include_once('tpl/news.tpl.php'); // your news template 
    break; 
    case "events": 
     require_once('inc/events.php'); 
     include_once('tpl/events.tpl.php'); 
    break; 
    case "contact": 
     require_once('inc/contact.php'); 
     include_once('tpl/contact.tpl.php'); 
    break; 
    default: 
     if ($_GET['filename']=="") { 
      include_once('tpl/home.tpl.php'); 
     } 
     else { 
      include_once('tpl/page_not_found.tpl.php'); 
     } 
    break; 
} 
?>

ऊपर, index.php नामक एक फाइल में, एक सरल नियंत्रक के रूप में कार्य करेंगे। छोटी-छोटी साइटों के लिए, मैं थोड़ा-अधिक जटिल-सेटअप के समान-समान उपयोग करता हूं। inc निर्देशिका में फ़ाइलों में आमतौर पर "व्यापार लॉगिन" होता है (उदाहरण के लिए inc/news.php में समाचार लेख आदि लाने के तरीकों के साथ एक कक्षा होगी) और फिर tpl निर्देशिका में टेम्पलेट फ़ाइलें।

ऑब्जेक्ट-ओरिएंटेड नहीं, लेकिन बुरा भी नहीं। यह मुझे निराश करता है, जो लोग अंधे कसम खाएंगे कि यदि यह वस्तु-उन्मुख नहीं है तो यह खराब कोड होना चाहिए।

स्रोत

2010-07-16 09:16:56

-1

निश्चित रूप से ओओ के साथ जाएं।

आपकी वेबसाइट कितनी छोटी होगी, यह हमेशा ओओ का उपयोग करके संशोधित/विस्तारित किया जा सकता है।

http://www.yiiframework.com/

पूरी तरह PHP5 में और OO :)

स्रोत

2010-07-19 18:30:20 eddy147

लोकप्रिय मिथक है कि प्रक्रियात्मक पूर्ण बी एस है एक्स्टेंसिबल नहीं है:

इसके अलावा, मैं एक बहुत अच्छा और त्वरित ढांचे की सिफारिश कर सकते हैं। यदि आप वास्तव में एक लाइव उदाहरण चाहते हैं, तो github में लिनक्स कर्नेल विकास पर एक नज़र डालें। इसमें कोई संदेह नहीं है कि यह दुनिया की सबसे जटिल परियोजनाओं में से एक है और इसका समुदाय पहले दिन से प्रेरित है। तो, तथ्य यह है कि सी पूरी तरह से संरचित और प्रकृति में प्रक्रियात्मक है, यह विस्तारशीलता को सीमित नहीं करता है। साथ ही, यह इंगित करने के लिए कि ओओपी मूल रूप से एक अवधारणा है जिसे PHP में अनुकरण किया जाता है। कम स्तर पर यह अंततः flattened। अपने तर्कों को अलग रखें और अलौकिक पुन: प्रयोज्य कार्य करें। उपयोगकर्ता इनपुट पर ध्यान केंद्रित करें और डेटा को स्वच्छ करें। डेटाबेस डिजाइन पर दृढ़ता से ध्यान केंद्रित करें। चूंकि लिनस ने एक बार कहा था "खराब प्रोग्रामर कोड पर ध्यान केंद्रित करते हैं, अच्छे प्रोग्रामर डेटा संरचना पर ध्यान केंद्रित करते हैं"।

स्रोत

2014-07-04 04:58:32 Gopal

ओओ या प्रक्रियात्मक PHP?

उत्तर

संबंधित मुद्दे