सरणी के बजाय ऑब्जेक्ट क्यों लौटाते हैं?


84

मैं वर्डप्रेस में बहुत काम करता हूं, और मैंने देखा है कि सरणियों की तुलना में कहीं अधिक फ़ंक्शन ऑब्जेक्ट लौटाते हैं। डेटाबेस परिणाम वस्तुओं के रूप में वापस कर दिए जाते हैं जब तक कि आप विशेष रूप से एक सरणी के लिए नहीं पूछते। त्रुटियां वस्तुओं के रूप में लौटाई जाती हैं। वर्डप्रेस के बाहर, अधिकांश एपीआई आपको एक सरणी के बजाय एक वस्तु देते हैं।

मेरा सवाल यह है कि वे सरणियों के बजाय वस्तुओं का उपयोग क्यों करते हैं? अधिकांश भाग के लिए यह बहुत ज्यादा मायने नहीं रखता है, लेकिन कुछ मामलों में मैं वस्तुओं को न केवल प्रक्रिया के लिए बल्कि अपने सिर को चारों ओर लपेटने के लिए कठिन पाता हूं। क्या किसी वस्तु का उपयोग करने का कोई कारण है?

मैं एक स्व-सिखाया PHP प्रोग्रामर हूँ। मुझे एक उदार कला की डिग्री मिली है। मुझे माफ कर दो अगर मुझे कंप्यूटर विज्ञान का एक बुनियादी पहलू याद आ रहा है। ;)


5
मैं वस्तुओं के नुकसान के संबंध में इस बारे में उत्सुक हूं , जैसे कि उन पर उपयोग count()या array_*()कार्य करने में सक्षम नहीं होना (कम से कम भंडारण / वापसी कुंजी => मूल्य डेटा के संबंध में)। कोई भी इसका उल्लेख नहीं करता है, या मैं कुछ याद कर रहा हूं?
वेस्ले मर्च

8
काउंटेबल या इटरेटर इंटरफेस को लागू करके वस्तुओं को गणना योग्य और पुनरावृति बनाया जा सकता है। साथ ही php.net/manual/en/book.spl.php देखें ।
बादशाह

यदि एसपीएल स्थापित किया गया है और आप अपने ऑब्जेक्ट-क्लास के लिए गणना करने योग्य इंटरफ़ेस लागू करते हैं तो आप count()किसी ऑब्जेक्ट पर कॉल कर सकते हैं ।
एसई

2
कई मामलों में, एक सरणी का भी कोई मतलब नहीं है क्योंकि आप वस्तुओं का संग्रह, या एक तरह का संग्रह नहीं लौटाते हैं जो आसानी से सरणियों के साथ अनुकरण नहीं करते हैं। जब आपके पास बस अन्य मूल्यों का एक क्रम होता है और कोई अतिरिक्त शब्दार्थ नहीं जुड़ा होता है, तो भगवान के लिए एक सरणी लौटाते हैं - लेकिन आप पाएंगे कि शायद ही कभी ऐसा हो।

8
@ डायलेन और अन्य: कृपया ध्यान दें कि @ डेनिस साहचर्य सरणियों के बारे में बात कर रहा है , (उर्फ। शब्दकोश, उर्फ ​​मैप्स), सामान्य नहीं (पूर्णांक-सूचकांक) सरणियाँ। ये PHP की एक मुख्य विशेषता हैं, और कमोबेश इसी उद्देश्य को गतिशील कक्षाओं ( stdClass) के रूप में प्रस्तुत करते हैं। मुझे यकीन नहीं है कि इस सवाल का एक और जवाब है "क्योंकि प्रोग्रामर जो मुख्य रूप से OOP में काम करते हैं वे वस्तुओं का उपयोग करने के शब्दार्थ को पसंद करते हैं"
BlueRaja - Danny Pflughoeft

जवाबों:


62

यही कारण हैं कि मैं सामान्य रूप से वस्तुओं को पसंद करता हूं:

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

यहाँ कुछ पढ़ने के लिए है:


3
लगता है कि पहला लिंक अच्छा नहीं है? मेरा मतलब है कि यह काम करता है, लेकिन एक अलग तरह से होता है
जियो

24

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

चलो कुछ उदाहरणों के माध्यम से चलते हैं।

  • यदि सरणियों को वापस कर दिया गया था, तो या तो सभी मूल्यों को आगे की गणना करने की आवश्यकता है या बहुत कम मूल्यों को वापस करने की आवश्यकता है, जिसके साथ आप अधिक जटिल मूल्यों का निर्माण कर सकते हैं।

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

यदि आप किसी सरणी में सभी पोस्ट वापस कर रहे हैं, तो आपको पोस्ट आईडी की एक सरणी वापस करने के लिए खुद को सीमित करना होगा:

[233, 41, 204, 111]

या एक बड़े पैमाने पर सरणी लौटाता है जो कुछ इस तरह दिखता है:

[ title: 'somePost', body: 'blah blah', 'author': ['name': 'billy', 'email': 'bill@bill.com', 'profile': ['interests': ['interest1', 'interest2', ...], 'bio': 'info...']] ]
[id: '2', .....]]

आईडी की सूची वापस करने का पहला मामला आपके लिए बहुत उपयोगी नहीं है क्योंकि तब आपको उस पोस्ट के बारे में कुछ जानकारी प्राप्त करने के लिए प्रत्येक आईडी के लिए एक एपीआई कॉल करने की आवश्यकता होती है।

दूसरा मामला 90% समय की आवश्यकता की तुलना में अधिक जानकारी खींचेगा और अधिक काम करने का तरीका होगा (खासकर यदि उन क्षेत्रों में से कोई भी निर्माण करने के लिए बहुत जटिल है)।

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

  • Arrays इरादा से अधिक डेटा और क्षमताओं को उजागर करता है

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

  • कार्यक्षमता

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

  • लचीलापन

उपरोक्त वर्णित सभी वस्तुओं के लाभ अधिक लचीली प्रणाली बनाने में मदद करते हैं।


10

मेरा सवाल यह है कि वे सरणियों के बजाय वस्तुओं का उपयोग क्यों करते हैं?

संभवतः दो कारण:

  • वर्डप्रेस काफी पुराना है
  • सरणियाँ तेज़ होती हैं और अधिकांश मामलों में कम मेमोरी लेती हैं
  • आसान बनाने के लिए

क्या किसी वस्तु का उपयोग करने का कोई कारण है?

उदाहरण के लिए बहुत सारे अन्य अच्छे कारण:

  • आप ऑब्जेक्ट्स में लॉजिक स्टोर कर सकते हैं (तरीके, क्लोजर आदि)
  • आप एक इंटरफ़ेस का उपयोग करके ऑब्जेक्ट संरचना को बाध्य कर सकते हैं
  • आईडीई में बेहतर स्वतः पूर्णता
  • आपको अपरिभाषित सरणी कुंजियों के लिए नोटिस नहीं मिलते हैं
  • अंत में, आप आसानी से किसी भी ऑब्जेक्ट को सरणी में बदल सकते हैं

OOP ! = AOP :)

(उदाहरण के लिए, रूबी में, सब कुछ एक वस्तु है। PHP पहले प्रक्रियात्मक / स्क्रिप्टिंग भाषा थी।)


7

वर्डप्रेस (और अन्य PHP अनुप्रयोगों की एक उचित मात्रा) तकनीकी कारणों के बजाय, वैचारिक के लिए, सरणियों के बजाय वस्तुओं का उपयोग करती है।

एक वस्तु (भले ही stdClass का एक उदाहरण है) एक चीज का प्रतिनिधित्व है। वर्डप्रेस में जो एक पोस्ट, एक टिप्पणी या एक उपयोगकर्ता हो सकता है। दूसरी ओर एक सरणी चीजों का एक संग्रह है। (उदाहरण के लिए, पदों की एक सूची।)

ऐतिहासिक रूप से, PHP में महान वस्तु का समर्थन नहीं था, इसलिए सरणियाँ बहुत जल्दी शक्तिशाली हो गईं। (उदाहरण के लिए, केवल शून्य-अनुक्रमित होने के बजाय मनमानी कुंजी रखने की क्षमता।) PHP 5 में उपलब्ध वस्तु समर्थन के साथ, डेवलपर्स के पास अब कुंजी-मूल्य स्टोर के रूप में सरणियों या वस्तुओं का उपयोग करने के बीच एक विकल्प है। व्यक्तिगत रूप से, मैं वर्डप्रेस दृष्टिकोण को पसंद करता हूं क्योंकि मुझे 'इकाइयां' और 'संग्रह' के बीच वाक्यविन्यास अंतर पसंद है जो ऑब्जेक्ट और सरणियां प्रदान करते हैं।


5

मेरा प्रश्न यह है कि वे (Wordpress) सरणियों के बजाय वस्तुओं का उपयोग क्यों करते हैं?

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

सहयोगी सरणियों के लिए सिंटैक्टिक चीनी - Zeev Suraski PHP 3 के बाद से मानक वस्तु के बारे में

  • stdClassऑब्जेक्ट वास्तव में सरणियों से बेहतर नहीं हैं। वे बहुत अधिक समान हैं। यह भाषा के कुछ ऐतिहासिक कारणों के साथ-साथ stdClassवस्तुएं वास्तव में सीमित हैं और वास्तव में एक बहुत ही मूल अर्थ में केवल वस्तुओं का मूल्य है।
  • stdClassऑब्जेक्ट अपने सदस्यों के लिए मानों को संग्रहीत करते हैं जैसे एक प्रविष्टि प्रति सरणी करती है। और बस।
  • केवल PHP फ्रीक stdClassनिजी सदस्यों के साथ ऑब्जेक्ट बनाने में सक्षम हैं । बहुत लाभ नहीं है - यदि कोई है - तो ऐसा करने से।
  • stdClassवस्तुओं का कोई तरीका / कार्य नहीं है। तो Wordpress में इसका कोई उपयोग नहीं है।
  • की तुलना में array, सूची या अर्ध-संरचित डेटा से निपटने के लिए बहुत कम सहायक कार्य हैं।

हालांकि, यदि आप सरणियों के लिए उपयोग किए जाते हैं, तो बस कास्ट करें:

$array = (array) $object;

और आप पहले से एक ऑब्जेक्ट के रूप में डेटा का उपयोग कर सकते हैं, एक सरणी के रूप में। या आप इसे दूसरे तरीके से पसंद करते हैं:

$object = (object) $array;

जो नंबरों की तरह ही अमान्य सदस्य नामों को छोड़ देगा। इसलिए थोड़ा ध्यान रखें। लेकिन मुझे लगता है कि आपको बड़ी तस्वीर मिलती है: जब तक यह सरणियों और वस्तुओं के बारे में है तब तक बहुत अंतर नहीं है stdClass

सम्बंधित:


4
  1. कोड उस तरह से कूलर लगता है
  2. संदर्भ से वस्तुएं गुजरती हैं
  3. ऑब्जेक्ट अधिक मजबूत टाइप किए जाते हैं फिर सरणियाँ, इसलिए त्रुटियों के लिए लीज़ सुनाई देती है (या जब आप अन-मौजूदा सदस्य का उपयोग करने का प्रयास करते हैं तो आपको एक सार्थक त्रुटि संदेश देते हैं)
  4. आज सभी IDE में स्वतः पूर्णता है, इसलिए परिभाषित वस्तुओं के साथ काम करते समय, IDE आपके लिए बहुत कुछ करता है और चीजों को गति देता है
  5. इग्नेली एक ही बॉक्स में तर्क और डेटा को एनकैप्सुलेट करता है , जहां सरणियों के साथ, आप डेटा को सरणी में संग्रहीत करते हैं, और फिर इसे संसाधित करने के लिए विभिन्न फ़ंक्शन के सेट का उपयोग करते हैं।
  6. वंशानुक्रम, यदि आपके पास लगभग समान नहीं बल्कि समान कार्यक्षमता के साथ एक समान सरणी है, तो आपको अधिक कोड डुप्लिकेट करना होगा, यदि आप इसे ऑब्जेक्ट्स के साथ करना चाहते हैं

शायद कुछ और कारण जिनके बारे में मैंने सोचा है


"# ऑब्जेक्ट्स संदर्भ से गुजरते हैं": यह गलत है। ऑब्जेक्ट एक PHP चर संदर्भ के रूप में पास नहीं होते हैं। उन्होंने कभी नहीं किया।
हकर्रे

@ ठाकरे - क्या आप php4 पर हैं? या कृपया विस्तृत करें कि आपका क्या मतलब है।
इते मूव -मालिमोवका

अच्छी तरह से नहीं है कि वर्डप्रेस हाल ही में PHP 4 तक नहीं था, लेकिन PHP 4 या PHP 5 में, ऑब्जेक्ट संदर्भ के रूप में पास नहीं होते हैं: "PHP5 OOP के प्रमुख बिंदुओं में से एक जो अक्सर उल्लेख किया गया है कि" ऑब्जेक्ट्स डिफ़ॉल्ट रूप से संदर्भों द्वारा पारित किए जाते हैं " यह पूरी तरह सच नहीं है। यह खंड कुछ उदाहरणों का उपयोग करके उस सामान्य विचार को ठीक करता है। " वस्तुएँ और संदर्भ
१२

@ ठाकरे - मैं देख रहा हूं कि आपका क्या मतलब है, लेकिन सभी उद्देश्यों के लिए, भाषा ऐसा व्यवहार करती है जैसे कि आप केवल संदर्भ देते हैं।
इते मूव -मालिमोवका

4

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

इसके अलावा, आपको जानकारी छिपाने के OO सिद्धांत पर विचार करना चाहिए। सब कुछ जो डेटाबेस से वापस आता है या नहीं जाता है, सीधे पहुंच योग्य होना चाहिए।


वर्डप्रेस कक्षा की वस्तुओं को लौटाता है StdClass। उन वस्तुओं में कुछ भी नहीं है जो आप को उजागर करते हैं। उनके पास उदाहरण के लिए कोई कार्य नहीं है और उनके पास विरासत नहीं है। और Wordpress के मामले में, सभी वर्ग चर सार्वजनिक हैं।
हक्रे

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

वे बस एक डेटाबेस हेल्पर वर्ग का उपयोग करते हैं जो stdClassसीए के बाद से डिफ़ॉल्ट रूप से ऑब्जेक्ट लौटाता है । 8 साल। यदि आप एक सरणी प्राप्त करना चाहते हैं, तो आपको इसे प्राप्त करने के लिए एक वैकल्पिक पैरामीटर सेट करना होगा।
हक्रे

3

वस्तुओं को वापस करने के कई कारण हैं:

  1. लेखन $myObject->propertyकी तुलना में कम "ओवरहेड" वर्णों की आवश्यकता होती है$myArray['element']

  2. ऑब्जेक्ट डेटा और कार्यक्षमता वापस कर सकता है; सरणियों में केवल डेटा हो सकता है।

  3. जंजीर सक्षम करें: $myobject->getData()->parseData()->toXML();

  4. आसान कोडिंग: आईडीई ऑटोकंप्लीमेंट ऑब्जेक्ट के लिए विधि और संपत्ति संकेत प्रदान कर सकता है।

प्रदर्शन के संदर्भ में, सरणियाँ अक्सर वस्तुओं की तुलना में तेज़ होती हैं। प्रदर्शन के अलावा, सरणियों का उपयोग करने के कई कारण हैं:

  1. सरणी _ * () फ़ंक्शन द्वारा प्रदान की गई कार्यक्षमता कुछ मामलों में आवश्यक कोडिंग की मात्रा को कम कर सकती है।

  2. काउंट () और फ़ॉरइच () जैसे कार्यों को एरेज़ पर किया जा सकता है। वस्तुएं इसे प्रदान नहीं करती हैं (जब तक कि वे Iterator या गणनीय को लागू नहीं करते हैं )।


2

यह आमतौर पर प्रदर्शन कारणों से नहीं होने वाला है। आमतौर पर, वस्तुओं की लागत सरणियों से अधिक होती है।

बहुत सारे API के लिए, संभवतः इसे स्टोरेज मैकेनिज्म होने के अलावा अन्य कार्यक्षमता प्रदान करने वाली वस्तुओं के साथ करना पड़ता है। अन्यथा, यह वरीयता का मामला है और किसी वस्तु बनाम सरणी को वापस करने का वास्तव में कोई लाभ नहीं है।


PHP5 में, सरणियों और वस्तुओं के बीच के प्रदर्शन में अंतर मामूली है।
जस्टिन ᚅᚔᚈᚄᚒᚔ

2

एक सरणी केवल मूल्यों का एक सूचकांक है। जबकि किसी ऑब्जेक्ट में ऐसी विधियाँ होती हैं जो आपके लिए परिणाम उत्पन्न कर सकती हैं। ज़रूर, कभी-कभी आप किसी ऑब्जेक्ट के मान को सीधे एक्सेस कर सकते हैं, लेकिन "इसे करने का सही तरीका" एक ऑब्जेक्ट के तरीकों (उस ऑब्जेक्ट के मूल्यों पर काम करने वाला फ़ंक्शन) तक पहुंचना है।

$obj = new MyObject;
$obj->getName();   // this calls a method (function), so it can decide what to return based on conditions or other criteria

$array['name'];   // this is just the string "name". there is no logic to it. 

कभी-कभी आप एक ऑब्जेक्ट चर को सीधे एक्सेस कर रहे हैं, यह आमतौर पर पर आधारित होता है, लेकिन यह अभी भी अक्सर होता है।

$obj->name;   // accessing the string "name" ... not really different from an array in this case.

हालाँकि, यह विचार करें कि MyObject क्लास में 'name' नाम का एक वैरिएबल नहीं है, लेकिन इसके बजाय एक first_name और last_name वैरिएबल है।

$obj->getName();  // this would return first_name and last_name joined.
$obj->name;  // would fail...
$obj->first_name; 
$obj->last_name; // would be accessing the variables of that object directly.

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


1

ज्यादातर समय वस्तुएं उतनी ही तेजी से होती हैं, अगर सरणियों से तेज नहीं होती हैं, तो PHP में ध्यान देने योग्य अंतर नहीं होता है। मुख्य कारण यह है कि वस्तुएं सरणियों से अधिक शक्तिशाली होती हैं। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग आपको ऑब्जेक्ट बनाने और न केवल डेटा स्टोर करने की अनुमति देता है, बल्कि उनमें कार्यक्षमता, उदाहरण के लिए PHP में MySQLi Class आपको डेटाबेस ऑब्जेक्ट की अनुमति देता है जो आप प्रक्रियात्मक दृष्टिकोण के बजाय इनबिल्ट फ़ंक्शन के होस्ट का उपयोग करके हेरफेर कर सकते हैं।

तो मुख्य कारण यह है कि OOP एक उत्कृष्ट प्रतिमान है। मैंने एक लेख लिखा था कि OOP का उपयोग करना एक अच्छा विचार क्यों है, और अवधारणा की व्याख्या करते हुए, आप यहाँ देख सकते हैं: http://tomsbigbox.com/an-introduction-to-oop/

एक मामूली से अधिक के रूप में आप भी वस्तु से डेटा प्राप्त करने के लिए कम टाइप करते हैं - $ परीक्षण-> डेटा $ परीक्षण ['डेटा'] से बेहतर है।


1

मैं शब्द प्रेस से अपरिचित हूं। यहां बहुत सारे उत्तर बताते हैं कि वस्तुओं की एक ताकत कार्यात्मक कोड को समाहित करने की क्षमता है। किसी फ़ंक्शन / API कॉल से किसी ऑब्जेक्ट को वापस करते समय इसमें उपयोगिता फ़ंक्शन नहीं होना चाहिए। बस गुण।

वस्तुओं को वापस करने में ताकत यह है कि एपीआई के पीछे जो कुछ भी है वह आपके कोड को तोड़ने के बिना बदल सकता है।

उदाहरण: आपको कुंजी / मान युग्म के साथ डेटा की एक सरणी मिलती है, कुंजी DB कॉलम का प्रतिनिधित्व करती है। यदि DB कॉलम का नाम बदल जाता है तो आपका कोड टूट जाएगा।


1

Im अगले परीक्षण php 5.3.10 (विंडोज़) में चल रहा है:

for ($i = 0; $i < 1000000; $i++) {
    $x = array();
    $x['a'] = 'a';
    $x['b'] = 'b';
}

तथा

for ($i = 0; $i < 1000000; $i++) {
    $x = new stdClass;
    $x->a = 'a';
    $x->b = 'b';
}

Http://atomized.org/2009/02/really-damn-slow-a-look-at-php-objects/comment-page-1/#comment-186961 से कॉपी किया गया

10 समवर्ती उपयोगकर्ताओं और 10 बार (औसत प्राप्त करने के लिए) के लिए फ़ंक्शन को कॉल करना

  • एरर्स: 100%
  • ऑब्जेक्ट: 214% - 216% (2 गुना धीमा)।

उर्फ, वस्तु यह अभी भी दर्दनाक धीमी है। OOP चीजों को चुस्त-दुरुस्त रखता है हालांकि इसे सावधानी से इस्तेमाल किया जाना चाहिए।

Wordpress क्या है? खैर, दोनों समाधान, वस्तुओं, सरणियों और ऑब्जेक्ट और सरणियों का उपयोग कर रहे हैं , क्लास wpdb बाद में उपयोग करता है (और यह वर्डप्रेस का दिल है)।


आपको PHP 5.4 पर तुलना देखनी चाहिए। वस्तुओं का प्रदर्शन बकाया है और कभी-कभी अर्रे से भी तेज है।
साकेत साहू

0

यह OOP के बॉक्सिंग और अनबॉक्सिंग सिद्धांत का अनुसरण करता है। जबकि जावा और C # जैसी भाषाएं इस मूल रूप से समर्थन करती हैं, PHP नहीं करता है। हालाँकि इसे पूरा किया जा सकता है, कुछ हद तक PHP में, सिर्फ वाक्पटुता नहीं है क्योंकि भाषा के पास इसका समर्थन करने के लिए निर्माण नहीं है। PHP में बॉक्स प्रकार होने से सब कुछ ऑब्जेक्ट ओरिएंटेड रखने में मदद कर सकता है और विधि हस्ताक्षर में टाइप करने के लिए अनुमति देता है। नकारात्मक पक्ष यह है कि तथ्य यह है कि अब आप अतिरिक्त जाँच कर रहे हैं कि निर्माण का उपयोग कर रहे हैं। एक प्रकार की प्रणाली होने के साथ-साथ विकास उपकरण का उपयोग करते समय एक प्लस भी होता है जिसमें पीडीटी की तरह इंटैलिजेंस या कोड असिस्ट होता है। विधि के लिए google / bing / yahoo होने के बजाय, यह ऑब्जेक्ट पर मौजूद है, और आप ड्रॉप डाउन प्रदान करने के लिए टूल का उपयोग कर सकते हैं।


0

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

इसका डेटा ट्रांसफर ऑब्जेक्ट - एक ऑब्जेक्ट जो प्रक्रियाओं के बीच डेटा को ले जाता है ताकि विधि कॉल की संख्या कम हो सके।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.