मॉडल को अपने प्रतिनिधित्व से अलग करने के लिए ऑब्जेक्ट ओरिएंटेड तरीका

Question

मान लें कि हमारे पास एक ऑब्जेक्ट है जो हार्डवेयर के एक टुकड़े की कॉन्फ़िगरेशन का प्रतिनिधित्व करता है। तर्क के लिए, एक तापमान नियंत्रक (TempController)। इसमें एक संपत्ति, सेटपॉइंट तापमान शामिल है।

मैं किसी अन्य डिवाइस में उपयोग के लिए एक फाइल करने के लिए इस विन्यास को बचाने के लिए की जरूरत है। फ़ाइल प्रारूप (स्वरूप ए) पत्थर में सेट है। मैं नहीं चाहता कि TempController ऑब्जेक्ट फ़ाइल प्रारूप के बारे में जान सके ... यह उस ऑब्जेक्ट के लिए प्रासंगिक नहीं है। इसलिए मैं एक और ऑब्जेक्ट बनाता हूं, "FormatAExporter", जो TempController को वांछित आउटपुट में बदल देता है।

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

दोनों फ़ाइल स्वरूपों दोनों उपकरणों का प्रतिनिधित्व करने में सक्षम हैं (मान अगर यह सेटिंग्स का अभाव AdvancedTempController उचित चूक है)। , कैसे दोनों ही मामलों को संभालने FormatBExporter कर सकते हैं 'इसा' या कुछ अन्य "धोखा दे" जिस तरह से मैं वस्तु की किस प्रकार यह पता लगाने की का उपयोग कर के बिना:

तो यहाँ समस्या है?

मेरा पहला वृत्ति प्रत्येक तापमान नियंत्रक में एक विधि है जो उस वर्ग के लिए ग्राहक निर्यातक प्रदान कर सकती है, उदाहरण के लिए, TempController.getExporter() और AdvancedTempController.getExporter()। यह एकाधिक फ़ाइल स्वरूपों का समर्थन नहीं करता है।

केवल अन्य दृष्टिकोण है कि दिमाग में स्प्रिंग्स प्रत्येक तापमान नियंत्रक कि गुण और उनके मान की सूची लौटाता में एक विधि है, और फिर फ़ॉर्मेटर कैसे उन उत्पादन के लिए तय कर सकते हैं। यह काम करेगा, लेकिन यह दृढ़ लगता है।

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

वहाँ कैसे मैं इस लचीला रखा हो सकता है के लिए कोई सुझाव हैं?

Answer 1

आप क्या कर सकते हैं TempControllers को सामान्य संग्रहकर्ता का उपयोग करके स्वयं को बनाए रखने के लिए जिम्मेदार होने दें।

class TempController 
{ 
    private Temperature _setPoint; 
    public Temperature SetPoint { get; set;} 

    public ImportFrom(Archive archive) 
    { 
     SetPoint = archive.Read("SetPoint"); 
    } 
    public ExportTo(Archive archive) 

    { 
     archive.Write("SetPoint", SetPoint); 
    } 
} 

class AdvancedTempController 
{ 
    private Temperature _setPoint; 
    private Rate _rateControl; 
    public Temperature SetPoint { get; set;} 
    public Rate RateControl { get; set;} 

    public ImportFrom(Archive archive) 
    { 
     SetPoint = archive.Read("SetPoint"); 
     RateControl = archive.ReadWithDefault("RateControl", Rate.Zero); 
    } 

    public ExportTo(Archive archive) 
    { 
     archive.Write("SetPoint", SetPoint); 
     archive.Write("RateControl", RateControl); 
    } 
} 

इसे इस तरह रखकर, नियंत्रकों परवाह नहीं कैसे वास्तविक मान जमा हो जाती है लेकिन आप अभी भी वस्तु अच्छी तरह से समझाया के आंतरिक रख रहे है।

अब आप एक सार पुरालेख वर्ग को परिभाषित कर सकते हैं कि सभी संग्रह वर्ग लागू हो सकते हैं।

abstract class Archive 
{ 
    public abstract object Read(string key); 
    public abstract object ReadWithDefault(string key, object defaultValue); 
    public abstract void Write(string key); 
} 

स्वरूप ए संग्रहकर्ता इसे एक तरह से कर सकता है, और FormatB संग्रह इसे अन्य कर सकता है।

class FormatAArchive : Archive 
{ 
    public object Read(string key) 
    { 
     // read stuff 
    } 

    public object ReadWithDefault(string key, object defaultValue) 
    { 
     // if store contains key, read stuff 
     // else return default value 
    } 

    public void Write(string key) 
    { 
     // write stuff 
    } 
} 

class FormatBArchive : Archive 
{ 
    public object Read(string key) 
    { 
     // read stuff 
    } 

    public object ReadWithDefault(string key, object defaultValue) 
    { 
     // if store contains key, read stuff 
     // else return default value 
    } 

    public void Write(string key) 
    { 
     // write stuff 
    } 
} 

आप किसी अन्य नियंत्रक प्रकार में जोड़ सकते हैं और जो भी फ़ॉर्मेटर पास कर सकते हैं। आप एक और फॉर्मेटर भी बना सकते हैं और इसे कंट्रोलर को पास कर सकते हैं।

Answer 2

मेरे पास "टेम्प नियंत्रक" होगा, एक getState विधि के माध्यम से, एक नक्शा वापस लौटाएं (उदाहरण के लिए पाइथन में एक नियम, जावास्क्रिप्ट में एक ऑब्जेक्ट में, सी ++ में एक std :: map या std :: hashmap, आदि आदि।) इसकी गुणों और वर्तमान मूल्यों के बारे में - इसके बारे में क्या गड़बड़ है ?! शायद ही सरल हो सकता है, यह पूरी तरह से एक्स्टेंसिबल है, और इसे उपयोग किए जाने वाले उपयोग से पूरी तरह से हटा दिया गया है (प्रदर्शित करना, क्रमबद्ध करना, & सी)।

Answer 3

FormatBExporter एक AdvancedTempController लेता है, तो आप एक पुल वर्ग TempController AdvancedTempController के अनुरूप करता है कि कर सकते हैं। हालांकि आपको कुछ प्रकार के getFormat() फ़ंक्शन को उन्नतTempController में जोड़ने की आवश्यकता हो सकती है।

उदाहरण के लिए:

FormatBExporter exporterB; 
TempController tempController; 
AdvancedTempController bridged = TempToAdvancedTempBridge(tempController); 

exporterB.export(bridged); 

वहाँ भी एक प्रमुख करने के लिए मूल्य मैपिंग योजना उपयोग करने का विकल्प है। FormatAExporter निर्यात/कुंजी "सेटपॉइंट" के लिए एक मान आयात करता है। FormatBExporter निर्यात/सेट "सेटपॉइंट" और "रेट कंट्रोल" के लिए मान आयात करता है। इस तरह, पुराना प्रारूपए एक्सपोर्टर अभी भी नया फ़ाइल प्रारूप पढ़ सकता है (यह सिर्फ "रेट्रोल" को अनदेखा करता है) और FormatBExporter पुराने फ़ाइल प्रारूप को पढ़ सकता है (यदि "रेट्रोल" गायब है, तो यह डिफ़ॉल्ट का उपयोग करता है)।

Answer 4

ठीक है, इसमें से बहुत से फ़ाइल प्रारूपों पर निर्भर करता है जिनके बारे में आप बात कर रहे हैं।

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

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

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

Answer 5

ओओ मॉडल में, सामूहिक रूप से ऑब्जेक्ट विधियां नियंत्रक हैं। अपने प्रोग्राम को एम और वी में अलग करने के लिए और अधिक उपयोगी है और यदि आप ओओ का उपयोग कर प्रोग्रामिंग कर रहे हैं तो सी नहीं।

Answer 6

C# या अन्य भाषाओं में है कि इस समर्थन आप यह कर सकते हैं:

class TempController { 
    int SetPoint; 
} 
class AdvancedTempController : TempController { 
    int Rate; 
} 

class FormatAExporter { 
    void Export(TempController tc) { 
     Write(tc.SetPoint); 
    } 
} 

class FormatBExporter { 
    void Export(TempController tc) { 
     if (tc is AdvancedTempController) { 
      Write((tc as AdvancedTempController).Rate); 
     } 
     Write(tc.SetPoint); 
    } 
} 

Answer 7

मुझे लगता है कि यह जहां Factory method pattern