विषयों में OOP का उपयोग करना

36

मुझे बहुत सारे प्लगइन्स दिखाई देते हैं जो वास्तव में आवश्यक नहीं होने पर ऑब्जेक्ट-ओरिएंटेड कोडिंग का उपयोग करते हैं।

लेकिन इससे भी बुरी बात यह है कि थीम डेवलपर्स एक ही काम करना शुरू कर रहे हैं। व्यावसायिक विषय और मुफ्त लोकप्रिय विषय जैसे कि सफ़्यूज़न, यहां तक कि मेरा पसंदीदा विषय - हाइब्रिड, एक कक्षा के अंदर अपने सभी कार्यों को भरता है, इसे फ़ंक्शन में एक बार त्वरित रूप से लिखता है और प्रक्रियात्मक तरीके से अपने कार्यों को चलाता है :)

WTF? ऐसा करने का क्या मतलब है? जाहिर है आप एक ही समय में एक ही विषय के दो या अधिक उदाहरणों का उपयोग नहीं करेंगे।

मान लेते हैं कि प्लगइन्स नेमस्पेस (जो हास्यास्पद है) के लिए ऐसा करते हैं, लेकिन विषय का बहाना क्या है? क्या मैं कुछ भूल रहा हूँ?

इस तरह एक विषय कोडिंग का क्या फायदा है?

themes php oop

— मंद बुद्धि होना
स्रोत

5

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

— माइकस्किंकल

1

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

— t31os

1

अजीब, बस मेरी मूल टिप्पणी खो गई (एसई बग शायद?) .. मैं इसे फिर भी दोहराऊंगा, कक्षा का उपयोग न करने के क्या अच्छे कारण हैं ?

— t31os

2

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

— onetrickpony

4

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

— माइकस्किंकल

26

मैं आपके द्वारा दिए गए उदाहरण के आधार पर आपके भ्रम को समझ सकता हूं। यह वास्तव में एक वर्ग का उपयोग करने का एक खराब तरीका है ... और सिर्फ इसलिए कि एक वर्ग का उपयोग किया जाता है, सिस्टम OOP नहीं बनाता है।

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

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

अपने सवालों के जवाब देने के लिए

WTF? ऐसा करने का क्या मतलब है? जाहिर है आप एक ही समय में एक ही विषय के दो या अधिक उदाहरणों का उपयोग नहीं करेंगे।

नहीं, आप एक ही विषय के दो या अधिक उदाहरणों का उपयोग नहीं करेंगे। लेकिन जैसा मैंने कहा, इस मामले में वर्ग संरचना के बारे में सोचें क्योंकि यह एक पारंपरिक वस्तु उदाहरण नहीं बना रहा है, कार्यों को नाम देना है। एक कक्षा में सब कुछ एक साथ लम्पिंग करना और या तो इसे कॉल करने के तरीकों ( myClass->method();) या कॉलिंग मेथड्स को सीधे करना ( myClass::method();) एक पठनीय, पुन: प्रयोज्य फैशन में चीजों को नामांकित करने का एक बहुत ही अच्छा तरीका है।

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

मान लेते हैं कि प्लगइन्स नेमस्पेस (जो हास्यास्पद है) के लिए ऐसा करते हैं, लेकिन विषय का बहाना क्या है? क्या मैं कुछ भूल रहा हूँ?

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

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

इस तरह एक विषय कोडिंग का क्या फायदा है?

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

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

— EAMann
स्रोत

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

— onetrickpony

मैं विषयों में OOP का उपयोग नहीं करने के लिए नहीं कह रहा हूं, जैसे कि यहां कुछ लोग समझ गए होंगे, इसके विपरीत (उदाहरण के लिए 2.8 विगेट्स देखें।, वॉकर आदि), लेकिन इस तरह नहीं।

— onetrickpony

1

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

— एमान

1

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

— onetrickpony

1

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

— एमान

29

गति

मेरे वर्तमान आधार विषय में 13 कक्षाएं हैं। जब मैं एक नया विषय बनाता हूं, तो मैं या तो इन वर्गों का उपयोग करता हूं या वे मुझे बढ़ाते हैं। यह प्रणाली एक नई थीम के निर्माण की प्रक्रिया को बहुत तेज, बहुत तेज बना देती है।

तंग स्कोप

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

रखरखाव

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

एक उदाहरण: comment_form();कॉल के ऊपर , मैं एक साधारण कार्रवाई का उपयोग करता हूं:

do_action( 'load_comment_class' );
comment_form();

कौन सा टिप्पणी वर्ग लोड किया जाएगा मेरे नियंत्रक तय करता है। टिप्पणी कक्षा के अंदर वास्तव में क्या होता है, यह व्यक्तिगत वर्ग तय करता है।

एक शुद्ध प्रक्रियात्मक दृष्टिकोण के साथ यह प्रयास करें और आप पागल हो रहे हैं। :)

पठनीयता

कुछ महीनों बाद अपने कोड को फिर से पढ़ना और समझना इतना आसान है यदि आपने इसके काम से सब कुछ अलग कर दिया है।

उपयोगी वर्ग पदानुक्रम के लिए कुछ उदाहरण

Meta_Box-> द्वारा बढ़ाया गया Shortdesc_Meta_Boxऔर Simple_Checkbox_Meta_Box-> द्वारा बढ़ाया गयाSidebar_Switch
User_Profile_Addon-> द्वारा विस्तारित User_Profile_Checkbox( प्रश्न 3255 देखें )
Comment_Form -> द्वारा बढ़ाया गया {$theme_name}_Comment_Form

— fuxia
स्रोत

1

अपनी 'थीम' कक्षाएं लेने का कोई मौका? मैं अपना खुद का लिखना चाहता हूं और मैं जानना चाहता हूं कि आप इसे कैसे करते हैं।

— हॉर्टकोर 12

1

मैंने अभी तक यह तय नहीं किया है। हो सकता है कि मैं अगले साल @bueltge के साथ एक नए आधार विषय को साकार कर रहा हूं जो इनमें से कुछ वर्गों का उपयोग करता है। मार्च से पहले बहुत संभावना है, मुझे डर है।

— FUXIA

5

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

— FUXIA

2

मैं हाइब्रिड के बारे में कुछ नहीं कह सकता; मैने इसे कभी इस्तेमाल नहीं किया है। लेकिन, हां, एक नियंत्रक जो पर्दे के पीछे सब कुछ व्यवस्थित करता है, अच्छे फिल्टर प्रदान करता है और कुछ एमवीसी पैटर्न को सामान्य थीम मेस में सम्मिलित करता है - ए गुड थिंग है। मुझ पर भरोसा मत करो। कोशिश करो। :)

— FUXIA

3

यह समय है, वर्डप्रेस को डेवलपर्स के लिए एक OOP विषय की आवश्यकता है; मुझे आशा है कि हम अपने लक्ष्य के लिए काम करने का समय निकालेंगे। यहां यह छोटा सा अंश और लाभ ग्राहक विषयों के लिए बहुत संभावनाएं दिखाते हैं; रखरखाव के लिए भी एक नया विषय ans का एहसास करने के लिए एक तेज़ तरीका।

— bueltge

3

विचार करने के लिए एक और बिंदु: गति।

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

एक छोटी नज़र / प्रिंट आउट के बाद मुझे ~ 1.700 आंतरिक फ़ंक्शन और ~ 1.400 उपयोगकर्ता फ़ंक्शन = ~ 3.100 / 3.200 फ़ंक्शन VS मिले। ~ 250 वर्ग। मुझे लगता है कि यह इस बारे में सबसे कहता है कि एक लुक की कितनी आवश्यकता होगी। यदि आप !function_exists('')अपने विषय में लगभग 50-100 कार्यों के लिए कॉल करते हैं ... बस एक टाइमर सेट करें और फिर कुछ गणित करना शुरू करें। भले ही यह OOP नहीं है, यह कोड बनाने का एक अच्छा तरीका है

1) पुन: प्रयोज्य
2) बनाए रखने योग्य
3) विनिमेय
4) थोड़ा तेज

जब आप वेब में घूमने वाले विभिन्न वर्गों पर नज़र डालते हैं, जो मेटा बॉक्स, विजेट आदि को तेज़ी से करने में आपकी मदद करते हैं, तो @toscho जैसे नियंत्रक का उपयोग करना अच्छा है, क्योंकि आप केवल कक्षाओं को प्लग इन कर सकते हैं और इनकी जगह ले सकते हैं नियंत्रक में कुछ पंक्तियाँ जो आपकी कक्षाओं को संभालती हैं।

— कैसर
स्रोत

2

कुछ लोगों का तर्क है कि इनकैप्सुलेशन एकमात्र (या कम से कम प्राथमिक) लाभ है जो ओओपी प्रदान करता है, और विरासत और राज्य उबाऊ और बुराई के बीच कहीं हैं:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

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

मैं अपना अगला वर्डप्रेस प्लगइन हास्केल में लिख सकता हूं।

— टेक्स
स्रोत

1

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

— जोश हबदास

2

ओह काफी चर्चा! मुझे यह भी स्वीकार करना होगा कि मैं इनकैप्सुलेशन के लिए कक्षाओं का उपयोग कहीं अधिक बार करता हूं। यह विचार यहां है कि मेरे प्लगइन्स में, मैं अपने कार्यों को एक कक्षा में लपेट सकता हूं, और उस वर्ग के भीतर बहुत ही सरल, अर्थपूर्ण तरीके के नाम का उपयोग करता हूं जो कि मेरे द्वारा लिखे गए अन्य प्लगइन्स में भी सामान्य हैं। उस उदाहरण में, कक्षाएं नेमस्पेस के लिए एक स्थानापन्न हैं, जिसे मैं 5.2.x वातावरणों से बचने के लिए मजबूर हूं।

हालांकि, कुछ उदाहरण हैं कि OOP प्रतिरूपकता के लिए उपयोगी है, आपके कार्यों को लपेटने का सरल कार्य क्रॉस-प्लगइन विस्तार की अतिरिक्त बोनस भी बनाता है। उदाहरण के लिए, मैंने हाल ही में एक इनवॉइसिंग सॉल्यूशन बढ़ाया था जो क्लास बेस्ड था, और ऐसे होने के नाते मैं मेन क्लास को बढ़ा सकता था, एक्सट्रा कोड को विभिन्न फंक्शन्स (w / पैरेंट :: कॉल्स) में ऐड कर सकता था या फंक्शन को रिप्लेस कर सकता था, बिना एक्सटेंड किए हुए प्लगइन को इंटरनल किए।

हालांकि, अधिकांश भाग के लिए वर्ग रैपिंग केवल नाम स्थान का एक विकल्प है।

— Jester831
स्रोत

-4

आपके द्वारा लिखे गए कोड के बारे में शिकायत करने का क्या मतलब है?

यदि आपको कोड पसंद नहीं है, तो अपना स्वयं का लिखें!

सरल। समस्या सुलझ गयी।

प्रोग्रामर अपने तरीके से सामान करना पसंद करते हैं। इसलिए यह न मानें कि आप उन्हें बता सकते हैं कि कोड कैसे लिखना है, किस तरह का व्हिस्की पीना है, किस ब्रांड का सिगरेट पीना है या किस धर्म का पालन करना है। वे सिर्फ ऐसे डायट्रीब को डिबग करेंगे और जो चाहते हैं, उसे करने पर सही रखेंगे। ;-)

कोड कविता नहीं है। कोड सिनात्रा गीत "माई वे" का एक रूप है ...

— निशान
स्रोत

10

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

— एमान