PHP में वेब विकास के लिए ओओ डिज़ाइन पैटर्न कितने प्रासंगिक हैं?

Question

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

बनाम एक गैर OOP दृष्टिकोण एक OOP का उपयोग performance में कुछ अंतर, गैर OOP एक बिट तेजी से होने के साथ हो सकता है, लेकिन अंतर व्यावहारिक रूप से नगण्य होगा।

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

Answer 4

कैसे प्रासंगिक वेब के लिए PHP अनुप्रयोगों के विकास में OO डिजाइन पैटर्न रहे हैं?

आईएमओ वे किसी भी गैर-तुच्छ PHP अनुप्रयोग के लिए बहुत प्रासंगिक हैं, जब तक आप जिस पैटर्न का उपयोग कर रहे हैं वह समस्या के लिए लागू है।

क्या यह प्रदर्शन के लिए कुछ भी करता है?

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

एक उदाहरण मैं सोच सकता हूं कि एक पैटर्न सीधे "प्रदर्शन" (स्मृति उपयोग के संबंध में) में सुधार करेगा, सिंगलटन पैटर्न का उचित उपयोग होगा। यदि आपको वास्तव में किसी भी समय किसी वस्तु के एक उदाहरण की आवश्यकता है, तो आप उस उदाहरण का उपयोग करके स्मृति उपयोग को कम करें।

या क्या यह केवल चुस्त विकास प्रथाओं के लिए कोड दुबला रखने के लिए है?

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

इन डिजाइन पैटर्न को लागू करने के लिए प्रमुख लाभकारी कौन है? क्या यह ग्राहक या डेवलपर है?

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

Answer 5

प्रक्रियात्मक प्रोग्रामिंग के लिए क्या एल्गोरिदम (क्विकसॉर्ट) हैं, डिजाइन पैटर्न उन्मुख डिजाइन को ऑब्जेक्ट करना है। वे कुछ आम समस्याओं को हल करने के लिए सिद्ध तरीका हैं।

मुख्य लाभकर्ता एक devolper है - लेकिन एक दुष्प्रभाव के रूप में एक ग्राहक शायद बेहतर अंतिम उत्पाद प्राप्त होगा।

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