इस PHP वर्ग संरचना में उपयोग करने के लिए उपयुक्त डिज़ाइन पैटर्न क्या होगा, बिना एकाधिक विरासत दिया?

Question

मेरे पास Node नामक एक अमूर्त वर्ग है। इसमें एक कन्स्ट्रक्टर होता है जो मेरे डेटाबेस से एक पंक्ति लेता है, और मूलभूत जानकारी को तुरंत चालू करता है। मेरी वेबसाइट पर सामग्री के सभी टुकड़े इस वर्ग का विस्तार - Person, Event, Project, आदि

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

एकाधिक विरासत सक्षम भाषा में, यह काफी सरल होगा; इन कक्षाओं में से कोई भी Node, और APIData, या ऐसा कुछ दोनों का विस्तार करेगा। एमआई के बिना, मुझे यकीन नहीं है कि इसे कैसे संभालें। एक इंटरफ़ेस का उपयोग करना सहायक नहीं होगा, क्योंकि यह कोई ठोस कार्यान्वयन प्रदान नहीं करता है।

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

Answer 1

चूंकि APIData कक्षा आपके Node कक्षा से कार्यक्षमता लेगी, तो आपको इसे विस्तारित करना चाहिए। यहाँ कुछ छद्म कोड है: "। ठीक है, मैं एक डेकोरेटर पैटर्न को लागू करने के लिए जा रहा हूँ"

abstract class APIData extends Node { 

    public function __construct($data) { 
     parent::__construct($data); 
     $this->checkData(); 
    } 

    protected function checkData() { 
     // load data from webservice 
     $data = $this->loadData(); 

     // check if data is the same 
     foreach($data as $item => $value) { 
      if ($this->data[$item] != $value) { 
       // save in database 
      } 
     } 
    } 
} 

Answer 2

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

यही कारण है कि मुझे लगता है कि आप सही पैटर्न के लिए संघर्ष कर रहे हैं, क्योंकि आपके ऑब्जेक्ट में कई चिंताएं हैं।

मुझे लगता है कि यहाँ का सबसे अच्छा तरीका एक सेवा है जो इस तरह के एक PersonService, EventService, आदि के रूप वस्तुओं, देता है, जो निम्न करता है बनाने के लिए किया जाएगा:

• डेटाबेस से रिकॉर्ड को पुनः प्राप्त
• हैं जाँच करने के लिए वेब सेवा की आवश्यकता है: परिवर्तन मौजूद, डेटाबेस को वापस सहेजते हैं
  • पुनः प्राप्त वेब सेवा
  • से डेटा
• पास रिकॉर्ड contructor आपत्ति उठाने
• वापसी वस्तु

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

Answer 3

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

किसी भी दर पर, मैं सुझाव दूंगा कि आप नीचे की बजाय ऊपर जाएं।Node को विस्तारित करने और APIData को किसी भी तरह से बल देने की बजाय, आप एक अलग ऑब्जेक्ट प्राप्त कर सकते हैं जो Node और APIData ऑब्जेक्ट्स से बना है और इसके माध्यम से उनके व्यक्तिगत कार्य करता है।

जब PHP 5.4 अपने गुणों के साथ आता है, तो यह इतना आसान होगा।