मैं PHP में ऑब्जेक्ट-ओरिएंटेड तरीके से डेटा कैसे पास करूं?


11

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

यह अच्छी तरह से वस्तु उन्मुख की मेरी समझ का पालन नहीं करता है। उदाहरण के लिए, अगर मैं जावा को कोड पोर्ट करने वाला था तो मैं उस तरह के आसपास ऐरे (या वैक्टर, या जो भी) गुजरने का सपना नहीं देखता।

मैं सोच रहा था कि क्या यह डेटा को संभालने का उचित तरीका है। क्या कोई कारण है कि PHP में सरणियों को इस तरह से पास किया जाता है, या वस्तुओं का उपयोग क्यों नहीं किया जाता है? डेटा पास करने का सबसे अच्छा तरीका क्या है?

जवाबों:


8

PHP के साथ Java के OO को भ्रमित न करें। जावा एक एकल प्रतिमान भाषा है जिसका अर्थ है कि यह केवल OO करता है। दूसरी ओर PHP एक बहु प्रतिमान भाषा है, आप या तो कार्यात्मक प्रोग्रामिंग या OO या दोनों कर सकते हैं।

अब ओओ के "खराब" कार्यान्वयन जैसी कोई चीज नहीं है। जावा का OO एक निश्चित कार्यान्वयन नहीं है जिसका हर दूसरी भाषा को पालन करना चाहिए। कुछ निश्चित अवधारणाएं हैं, और दोनों भाषाएं उन्हें अपने तरीके से पूरी तरह से लागू करती हैं (जावा शुरुआत से, पीएचपी 5 संस्करण के बाद से)।

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

यदि आप PHP के साथ शुरू कर रहे हैं तो अच्छे OO प्रथाओं के लिए संदर्भ के रूप में जावा का उपयोग करें लेकिन "जावा इसे अलग तरह से करता है" चीज के कारण PHP की अपनी समझ को सीमित न करें। आप वास्तव में दोनों में पेंच कर सकते हैं, यदि आप अवधारणा नहीं प्राप्त करते हैं तो प्रतिमान आपको नहीं बचाएगा।

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


हमें PHP OO के साथ Java OO को भ्रमित क्यों नहीं करना चाहिए? वे बहुत ही समान हैं, सिवाय इसके कि PHP में एक मूल सरणी / हैश डेटाटाइप है।
मार्टिन विकमैन

कार्यान्वयन काफी समान हैं। मैं यह जिक्र कर रहा था कि दोनों भाषाओं में उनका कैसे उपयोग किया जाता है।
यनीस

मैं OOP में एक मुद्दा है। मैं एक आवेदन (PHP बेस) के लिए ओओपी डिज़ाइन बनाना चाहता हूं, जहां एक ऑब्जेक्ट अन्य वस्तुओं पर निर्भर करेगा। मैं इसे PHP में कैसे संभालूं? plz मेरी मदद करें ...
इमरान खान

उदाहरण परिदृश्य: होटल ऑब्जेक्ट में रूम ऑब्जेक्ट होता है, जहाँ एक रूम ऑब्जेक्ट को ऑब्जेक्ट्स डेट करना होता है ... और एक डेट ऑब्जेक्ट में व्यक्ति प्रकारों के लिए मूल्य होते हैं। अब OOP आधार द्वारा PHP में इस प्रकार के परिदृश्य को कैसे संभालना है (क्योंकि बड़े डेटा हैं जिन्हें प्रत्येक स्तर पर प्रसंस्करण की आवश्यकता है)।
इमरान खान

@Walter मैं आपकी प्रतिक्रिया की प्रतीक्षा कर रहा हूं .... plz मेरी मदद करें।
इमरान खान

2

ऑब्जेक्ट को केवल सरणियों के बजाय उपयोग करना क्योंकि यह ऑब्जेक्ट OO प्रतिमान नहीं है, यह केवल व्यक्तिगत प्राथमिकताएँ है :)

ऑब्जेक्ट IDE में काम कोड को पूरा करते हैं, इंटरफेस (टाइप हिंटिंग) और इनहेरिटेंस का उपयोग किया जा सकता है।

यदि आप सरणी के बजाय ऑब्जेक्ट का उपयोग करना चाहते हैं क्योंकि आप कोई लाभ देखते हैं - उनका उपयोग करें, लेकिन यदि आप उन्हें केवल इसलिए उपयोग करना चाहते हैं क्योंकि यह ऑब्जेक्ट हैं - अपना समय इस रिफ्लेक्टरिंग में बर्बाद न करें :)


" ऑब्जेक्ट केवल सरणियों के रूप में उपयोग करें और अधिक मेमोरी और सीपीयू ले जाएगा। " यह (हमेशा) सच नहीं है। किसी सरणी के साथ समान मात्रा में डेटा रखने वाली वस्तु मेमोरी की लगभग समान मात्रा पर कब्जा कर लेगी।
यानिस

@ यानिस रिज़ोस, हाँ, ऑब्जेक्ट भी कम मेमोरी का उपयोग कर सकते हैं, संपादित।
OZ_

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

@ हेन हेनरिच, मुझे यह पता है, धन्यवाद। इसलिए मेरे जवाब से 'मेमोरी' के बारे में सभी शब्द हटा दिए गए। मैं मूर्खतापूर्ण अनुकूलन करने की कोशिश नहीं कर रहा हूं, लेकिन मुझे यकीन है कि objects just because they are objectsरिफैक्टिंग का एक कारण नहीं है :) मेरा जवाब पढ़ें, न केवल टिप्पणियां।
OZ_

काफी हद तक, मैंने संपादन से पहले टिप्पणी की।
रीन हेनरिक्स

1

आप वास्तव में OO सिस्टम में डेटा पास नहीं करते हैं - आप ऑब्जेक्ट को पास करते हैं। अंतर यह है कि वस्तुओं में व्यवहार के साथ-साथ डेटा भी होता है। इसलिए वे इसे ऑब्जेक्ट ओरिएंटेड कहते हैं न कि डेटा ओरिएंटेड।

जब तक आपके डेटा के साथ आपके व्यवहार की आवश्यकता नहीं होती है, तब सादे पुराने php सरणियाँ मूल्य वस्तुओं के रूप में केवल अच्छे (या खराब, आपके दृष्टिकोण पर निर्भर करती हैं) हैं।


0

मुझे लगता है कि यह सिर्फ समायोजन का सवाल है - प्रोग्रामिंग में "ऑब्जेक्ट्स" के कई कार्यान्वयन हैं - पायथन और जावास्क्रिप्ट में हड़ताली अलग-अलग गुण हैं। PHP OO यकीनन एक हैक है - PHP सरणियाँ पारंपरिक अर्थों में "ऑब्जेक्ट" नहीं हैं - लेकिन वे एक स्पष्ट उद्देश्य की सेवा करते हैं। जब तक आप चाहते हैं कि डेटा में कस्टम BEHAVIOR हो तो किसी ऑब्जेक्ट का उपयोग क्यों करें?

संपादित करें:

पुन: अपरिवर्तनीय मूल्य वस्तुओं

http://bradley-holt.com/2010/09/immutable-value-objects-in-php/


डेटा को एक विश्वसनीय संरचना देने के लिए। हां, मैं एक ऐसे फंक्शन का निर्माण कर सकता हूं जो किसी विशेष फॉर्मेट / नेस्टिंग ऑफ एरे को आउटपुट करता हो, लेकिन यह कहना कि मैं एक और फंक्शन नहीं लिखता जो इसे थोड़ा संशोधित करता है और फिर इसे पास करता है।
मैथ्यू

1
सुनिश्चित करें - तब आपको चर पहुंच की रक्षा के लिए एक ऑब्जेक्ट की आवश्यकता होगी - चूंकि उदाहरण के लिए पायथन ट्यूपल्स के कोई PHP समकक्ष नहीं हैं। लेकिन आप वहां जाते हैं - आपने समस्या को परिभाषित किया है, आपको बस भाषा के लिए उपलब्ध निर्माणों का उपयोग करना है ... या बस इसके साथ रहना सीखें "quirks"। मैंने अपनी प्रारंभिक पोस्ट के लिए एक लिंक जोड़ा है जिसमें समस्या की एक दिलचस्प चर्चा है।
सूर्यमुखी २
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.