2009-11-17 9 views
12

मेरे पास कैलेंडर ईवेंट ऑब्जेक्ट है। मेरे पास CalDAV/iCal/vCal प्रोटोकॉल/फ़ाइल प्रारूपों के साथ संगत बनाने की योजना है, जिसके लिए ईवेंट को क्रमबद्ध किया जाना चाहिए और विभिन्न प्रारूपों से और सीरियलकृत किया जाना चाहिए।आयात/निर्यात के लिए मुझे किस डिजाइन पैटर्न का उपयोग करना चाहिए?

मैं एक ImportICal, ExportICal, ImportVCal, ExportVCal, आदि तरीकों में से सेट लिख सकता है, लेकिन यह एक बहुत अच्छा दृष्टिकोण की तरह प्रतीत नहीं होता है, क्योंकि क्या हुआ अगर vCal प्रारूप अद्यतन किया जाता है, आदि

है किसी ने इस प्रकार के आयात/निर्यात की स्थिति से पहले निपटाया? यदि हां, तो कौन सा डिज़ाइन पैटर्न (यदि कोई है) आमतौर पर सबसे अच्छा होता है?

आपकी मदद के लिए धन्यवाद!

उत्तर

19

मैं उन प्रारूपों से परिचित नहीं हूं लेकिन मैं एक साधारण डेटा स्थानांतरण ऑब्जेक्ट तैयार करूंगा जो आपके जीनेरिक कैलेंडर ईवेंट ऑब्जेक्ट का प्रतिनिधित्व करता है। यह डेटा (स्यूडोकोड) पकड़े लेकिन कुछ नहीं करता है:

interface ICalendarEventReader 
{ 
    CalendarEvent Read(Stream data); 
    // Add additional methods if needed e.g.: 
    string GetTitleOnly(Stream data); 
} 
interface ICalendarEventWriter 
{ 
    Stream Write(CalendarEvent event); 
    // Add additional methods if needed e.g.: 
    Stream WriteSummaryOnly(CalendarEvent event); 
} 
:

class CalendarEvent 
{ 
    DateTime Date { get; } 
    string Title { get; } 
    string Description { get; } 
} 

तो फिर तुम CalendarEventReader और CalendarEventWriter के लिए एक इंटरफेस बनाने (यह रणनीति पैटर्न और शायद बिल्डर पैटर्न, एक तरह से है)

फिर वास्तविक कार्यान्वयन उपर्युक्त इंटरफेस को लागू करते हैं। प्रत्येक प्रारूप के लिए एक।

class CalDavConverter : ICalenderEventWriter, ICalendarEventReader 
{ 
    ... 
} 

फिर आप एक भंडार होगा (यह फैक्टरीसिंगलटन साथ पैटर्न शायद है) कि ICalenderEventReader/लेखक कार्यान्वयन की एक सूची रखता: तुम भी एक ही कक्षा में पाठक और लेखक होने के बारे में सोच सकते हैं विभिन्न स्वरूपों के लिए: (आपके मामले में कैलेंडर प्रोटोकॉल) कई कार्यान्वयन की व्यवस्था करने के

static class CalenderEventConverterRepository 
{ 
    static ICalendarEventReader GetReader(string formatName /*or any other data upon wich to decide wich format is needed*/) 
    { 
    ... 
    } 

    static ICalendarEventReader GetWriter(string formatName /*or any other data upon wich to decide wich format is needed*/) 
    { 
    ... 
    } 
} 
+3

मुझे नहीं लगता कि पाठक लेखक इंटरफेस को बिल्डर कहा जा सकता है। लेकिन इसके अलावा, एक अच्छा डिजाइन सुझाव के लिए +1। – Tanmay

+0

जिस समाधान का मैं अपने साथ आया था वह समान था (फैक्ट्री भाग से कम)। क्लाइंट कोड तब कैसा दिखता है? क्या कैलेंडर ऑब्जेक्ट उस फैक्ट्री का उपयोग करेगा, या क्लाइंट कोड इसका उपयोग करेगा? –

0

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

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

0

हमेशा की तरह कोई एक सामान्य इंटरफेस के साथ Bridge Pattern है।

+0

इसका मतलब यह होगा कि मैं कैलेंडरवेवेंट ऑब्जेक्ट के निर्माता को ICalExporter का कार्यान्वयन पास करूंगा। फिर, कैलेंडरइवेंट ऑब्जेक्ट पर, मैं निर्यात() को कॉल करता हूं और यह उस प्रारूप को निर्यात करने के लिए ICalExporter ऑब्जेक्ट का उपयोग करता है जो भी प्रारूप में है। अगर मुझे दोनों प्रारूपों में इसकी ज़रूरत है तो क्या होगा? –

+0

आप इसके लिए समग्र पैटर्न का उपयोग कर सकते हैं – jimkont

संबंधित मुद्दे