ओओपी सर्वोत्तम व्यवहार (विशेष रूप से PHP)

Question

मैं थोड़ी देर के लिए PHP में विकास कर रहा हूं लेकिन हाल ही में केवल एक ओओपी दृष्टिकोण पर स्विच कर दिया गया है।

एक सवाल है कि मेरे लिए ऊपर फसल रहता है 'कितनी दूर', OOP सामान के साथ जाने के लिए विशेष रूप से स्मृति संसाधनों आदि

उदाहरण के लिए निष्पादन की गति के मामले में, मान लीजिए कि मैं 2 वस्तुओं डालते हैं, उपयोगकर्ता और लिस्टिंग

लिस्टिंग हमेशा एक व्यक्तिगत उपयोगकर्ता से जुड़ी हुई हैं। UserId लिस्टिंग की एक संपत्ति है, इसलिए मुझे पता है कि यह किस उपयोगकर्ता से संबंधित है। एक समय में, एक लिस्टिंग विधि के भीतर मुझे संबंधित उपयोगकर्ता की एक ही संपत्ति तक पहुंचने की आवश्यकता है।

जहां तक ​​मैं देख सकता हूं (कृपया सलाह दें अगर नहीं) मेरे पास इसे पूरा करने के लिए 3 विकल्प हैं।

1. एक नया उपयोगकर्ता वस्तु बना सकते हैं और उपयोगकर्ता $ के माध्यम से प्रासंगिक प्रॉपर्टी का उपयोग -> theProperty

2. आवश्यक संपत्ति लिस्टिंग की एक स्थानीय संपत्ति बनाने और इस पॉप्युलेट जब लिस्टिंग initialised है (उदाहरण के लिए एक एसक्यूएल के माध्यम से शामिल होने के)

3. क्वेरी डेटाबेस सीधे उपयोगकर्ता की संपत्ति यूजर आईडी के माध्यम से आवश्यक पुनः प्राप्त करने के

यह प्रतीत मुझे यह विकल्प है कि विकल्प 1 & 2 ओओपी नियमों द्वारा अधिक कठोर रूप से बाध्य होते हैं, लेकिन 1 संपत्ति को पुनर्प्राप्त करने के लिए पूरी ऑब्जेक्ट को प्रारंभ करने के कारण प्रदर्शन हिट होती है। विकल्प 3 कम से कम स्मृति गहन होगा लेकिन पूरी तरह से ओओपी को हटा देगा।

इसके अलावा, सृजन पर आबादी वाले वस्तुओं के संदर्भ में, मेरी अधिकांश वस्तुओं को प्रारंभिक होने के तुरंत बाद एक 'भरने' विधि के माध्यम से अपनी अधिकांश संपत्तियां मिलती हैं (इसलिए केवल 1 डीबी क्वेरी की आवश्यकता होती है)। क्या इसे आम तौर पर सर्वोत्तम अभ्यास माना जाएगा, या इन गुणों को प्राप्त करने के लिए अलग-अलग तरीकों का उपयोग करने के लिए और अधिक सलाह दी जाएगी, जब उन्हें आवश्यकता हो और पॉप्युलेट किया जाए?

मुझे एहसास है कि इसके लिए "सही" जवाब नहीं हो सकते हैं, लेकिन क्या कोई इस स्थिति तक पहुंचने के सर्वोत्तम तरीकों पर सलाह दे सकता है?

बहुत धन्यवाद निक

Answer 1

मैं निश्चित रूप से विकल्प पसंद करते हैं 1. विकल्प 2 OOP के पीछे विचार का पालन नहीं करता है क्योंकि उपयोगकर्ता जानकारी आपकी प्रविष्टि का हिस्सा नहीं है, तो एक अलग वस्तु में रखें। एक ही बार में अपने संबंधों के बिना

1. लोड एक वस्तु:

   मन में निम्नलिखित नियम रखें।

2. आप एक संबंधित वस्तु बार जब आप नियम 1

कई ORMs इस तरह से काम करने के लिए अनुसार इसकी जरूरत पर इसे लोड, उदाहरण के लिए सिद्धांत (http://www.doctrine-project.org) की जरूरत है। इसे आलसी लोडिंग कहा जाता है।

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

Answer 2

मेरा मानना ​​है कि आप डाटा ट्रांसफर करने के लिए एक बार देख लेने की जरूरत ऑब्जेक्ट्स डिज़ाइन पैटर्न:

• http://en.wikipedia.org/wiki/Data_transfer_object

दृश्य (पृष्ठों) डाटा अंतरण वस्तुओं जो एक ही लोगों को नहीं होना चाहिए प्राप्त करना चाहिए कि आपकी डेटा-एक्सेस परत के साथ काम करते हैं।

कुछ पैरामीटर के साथ, आपकी व्यावसायिक परत डीटीओ वापस कर सकती है जिसमें डेटा-एक्सेस परत द्वारा लौटाए गए एक या अधिक ऑब्जेक्ट का एक विशिष्ट सेट होता है।

उदाहरण के लिए, यदि आप उपयोगकर्ताओं को सूचीबद्ध करना चाहते हैं, तो शायद आप उनके "समूह पहचानकर्ता", "उपयोगकर्ता पहचानकर्ता" और "पूर्ण नाम" को जानना चाहते हैं।

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

Answer 3

विकल्प 1 पसंदीदा ओओपी तरीका है।

वैकल्पिक रूप से, php में आप रैपर ऑब्जेक्ट लिख सकते हैं जिसमें केवल उपयोगकर्ता_आईडी और गुणों की आवश्यकता होती है।

और जब कोई विधि कहलाती है या दूसरी संपत्ति का उपयोग किया जाता है तो आप वास्तविक उपयोगकर्ता ऑब्जेक्ट को लोड और आरंभ कर सकते हैं।

यह प्राप्त किया जा सकता है जो __get(), __set() और __call() विधियों को प्राप्त किया जा सकता है।

इस तरह आप आवश्यकता होने पर उपयोगकर्ता ऑब्जेक्ट से सभी ओओपी भलाई तक पहुंच के दौरान लिस्टिंग ऑब्जेक्ट की क्वेरी और मेमोरी उपयोग को अनुकूलित कर सकते हैं।

class LazyObject { 

    private 
    $propertySubset = array(), 
    $realObject; 


function __call($method, $args) { 
    if ($this->realObject === null) { 
     $this->initRealObject(); 
    } 
    return call_user_func_array(array($this->realObject, $method), $args); 
    } 

    // __get, __set and initRealObject implementation goes here 

}

चेतावनियां

• आप संदर्भ का उपयोग कर सकते हैं:: myMethod(&$ref) और $shortcut = &$object->prop अभ्यस्त काम
• आप करेंगे

  संहिता की पंक्तियों के साथ कुछ ऐसा दिखाई देगा मैन्युअल रूप से जांचने की आवश्यकता है कि आपने टी भर दी है या नहीं वह पर्याप्त गुणों के साथ रैपर। पर्याप्त गुणों के परिणामस्वरूप बहुत सारे प्रश्न नहीं होंगे और रैपर केवल पतला हो जाएगा। जब तक आप उन्हें lazyObject में लागू

पुनश्च

इंटरफेस (ArrayAccess की तरह) का उपयोग काम नहीं करेगा।
इसे इष्टतमकरण हैक माना जाना चाहिए। तो यह केवल तभी कार्यान्वित करें जब प्रदर्शन एक मुद्दा बन रहा हो;

Answer 4

विकल्प # 1 पर भागने से पहले, मैं यह बताने की अनुशंसा करता हूं कि डेटाबेस में संग्रहीत डेटा के लिए एक साधारण ऑब्जेक्ट मॉडल लागू करने का प्रयास करने से बहुत जटिलताएं आ सकती हैं।

बस मैं क्या कह रहा हूँ की एक विचार है करने के लिए इस पढ़ें: "Why did object oriented databases fail"

आप कहते हैं कि निक है, वहाँ एक "सही" जवाब नहीं है। लेकिन हम यह कह सकते हैं:

ओओपी आदर्श अच्छे अभ्यास में, $ लिस्टिंग ऑब्जेक्ट में $ लिस्टिंग-> उपयोगकर्ता संपत्ति होनी चाहिए जो कि प्रविष्टि के उपयोगकर्ता का प्रतिनिधित्व करने वाली वस्तु है। बेहतर प्रदर्शन के लिए, जैसे ही $ लिस्टिंग तत्काल हो जाती है, इस उपयोगकर्ता ऑब्जेक्ट को तत्काल नहीं किया जाना चाहिए। जावा पारंपरिक कोडिंग में, आपके पास एक विधि होगी -> getUser()। जैसे ही आप -> उपयोगकर्ता संपत्ति के लिए कॉल करते हैं, आप PHP में इस ऑब्जेक्ट को तुरंत चालू कर सकते हैं।

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

यदि ऐसा है, तो आपको अपनी व्यावसायिक प्रक्रिया के करीब होने के लिए आदर्श ऑब्जेक्ट मॉडल से थोड़ा रास्ता तय करना होगा। फिर केवल उस उपयोगकर्ता संपत्ति को पुनर्प्राप्त करना जो आपको चाहिए, यह एक अच्छा समझौता हो सकता है। उदाहरण के लिए: $ लिस्टिंग-> getUserProp1()। यदि आपको भविष्य में अन्य उपयोगकर्ता गुणों की आवश्यकता हो सकती है तो आप विधि को $ listings-> getUserProprty ('prop1') में बदल सकते हैं।

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