ग्रहण

Question

में IProject.setDescription द्वारा कौन सा डिज़ाइन पैटर्न उपयोग किया जाता है, मैं एक विशिष्ट पैटर्न के साथ एक एपीआई डिज़ाइन कर रहा हूं, लेकिन यह नहीं पता कि इस पैटर्न का नाम क्या है या नहीं। यह गोफ (चार गिरोह) में कमांड पैटर्न के समान है लेकिन बिल्कुल नहीं।

मैं पा सकते हैं इसका एक सरल उदाहरण ग्रहण में वह जगह है जहाँ आप एक परियोजना (IProject), नहीं परियोजना है कि अपने राज्य को बदलने पर तरीकों को फोन करके हेरफेर, लेकिन यह 3 चरणों वाली प्रक्रिया द्वारा:

1. getDescription
2. की स्थापना वर्णनकर्ता पर गुणों के साथ एक विवरणक वस्तु (IProjectDescription) में अपने राज्य निकालने। जैसे setName
3. setDescription

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

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

इसमें ट्रांज़ेक्शनल एपीआई के कुछ गुण भी हैं, जिसमें set... कॉल के साथ सभी हिट में परिवर्तन करके, आप पूरी संशोधन को प्रभावी रूप से "रोल वापस" करने की अनुमति देते हैं यदि कोई भी संपत्ति परिवर्तन विफल हो जाता है। लेकिन जब यह दृष्टिकोण का एक फायदा है, यह वास्तव में इसका मुख्य उद्देश्य नहीं है। और क्या अधिक है, आप लेन-देन संबंधी प्रकृति इस दृष्टिकोण के बिना, प्राप्त कर सकते हैं बस एपीआई (जैसे commit और rollback)

कि मैं शोषण करना चाहते हैं इस पद्धति में दो फायदे हैं करने के लिए लेन-देन संबंधी विधियां जोड़कर - हालांकि मैं डॉन ' टी देख उनके ऊपर ग्रहण उदाहरण के द्वारा शोषण किया जा रहा:

1. आप अंतर्निहित वस्तु, जबकि इसके कार्यान्वयन परिवर्तन की सार्थक राज्य का प्रतिनिधित्व कर सकते हैं। यह विभिन्न प्रकार के प्रतिनिधित्व से राज्य को अपग्रेड करने या कॉपी करने के लिए उपयोगी है। मान लें कि मैं अपने एपीआई का एक नया संस्करण जारी करता हूं जहां मैं एक ऑब्जेक्ट Foo2 बनाता हूं जो कि मेरे पुराने Foo1 का एक बिल्कुल नया रूप है, लेकिन दोनों में समान मूल गुण हैं। Foo1 को Foo2 में अपग्रेड करने के लिए, मैं उन गुणों को FooState के रूप में निकाल सकता हूं। foo2.setFooState (foo1.getFooState) बस के रूप में। जिस तरह से गुणों का व्याख्या और प्रतिनिधित्व किया जाता है, वह फूस में encapsulated है और पूरी तरह से अलग हो सकता है।

2. मैं अपने सरल डेटा ऑब्जेक्ट के साथ अंतर्निहित वस्तु की स्थिति को जारी और प्रसारित कर सकता हूं, जहां ऑब्जेक्ट स्वयं ही जटिल होगा। तो मैं फू स्टेट को फूस्टेट के रूप में निकाल सकता हूं, और इसे एक साधारण एक्सएमएल दस्तावेज़ के रूप में जारी रख सकता हूं और बाद में इसे "लोडिंग" करके इसे लागू करके इसे लागू कर सकता हूं। या मैं बस JSON ऑब्जेक्ट के रूप में एक webservice पर FooState को प्रेषित कर सकता हूं जबकि Foo स्वयं संचार करने के लिए बहुत बड़ा और जटिल है।(या सेवा कॉल के प्रत्येक छोर पर वस्तुओं Foo1 और foo2 की तरह, पूरी तरह से अलग कर रहे हैं)

वैसे भी, मैं कहीं भी एक नाम या इस पद्धति का उदाहरण नहीं मिल सकता है, न तो the Gang of Four design patterns में, न ही में मार्टिन फाउलर का comprehensive "bliki"

Answer 1

Data Transfer Object (डीटीओ) कि मार्टिन Fowler अपनी पुस्तक Principles of Enterprise Application Architecture में वर्णन उद्देश्य आप बिंदु से वर्णन 2.

एक डीटीओ और अधिक जटिल डोमेन मॉडल है कि यह प्रतिनिधित्व करता है एक अत्यंत साधारण निष्कर्षण है के लिए हो रहा है।

फाउलर का वर्णन है कि एक असेंबलर के साथ संयोजन में डीटीओ का उपयोग डीटीओ को वास्तविक डोमेन ऑब्जेक्ट (या ऑब्जेक्ट्स) से स्वतंत्र रखने के लिए किया जा सकता है जिसे इसे प्रस्तुत करना है। असेंबलर जानता है कि डोमेन ऑब्जेक्ट से डीटीओ कैसे बनाया जाए और इसके विपरीत। इसके अलावा उन्होंने उल्लेख किया कि डीटीओ को अपने राज्य को जारी/प्रसारित करने के लिए क्रमिक होना आवश्यक है। प्वाइंट 2 में आप जो वर्णन करते हैं वह इस वर्णन से मेल खाता है।

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

मुझे यकीन नहीं है कि क्या आप अपनी पुस्तक या पुस्तक के पैटर्न सूची में गए हैं। पुस्तक स्वयं ही बहुत अधिक विस्तार से इसका वर्णन करती है।

आप ओरेकल से Transfer Object परिभाषा को भी देखना चाहते हैं, जो फाउलर कहते हैं here वह डीटीओ के रूप में वर्णन करता है।

Answer 2

प्रत्येक डिज़ाइन को एकल डिज़ाइन पैटर्न के रूप में दस्तावेज नहीं किया जाता है, वास्तव में अधिकांश सिस्टम डिज़ाइन कई पैटर्न के संयोजन होते हैं।

हालांकि आप जो कर रहे हैं उसका एक हिस्सा IProjectDescription के साथ Memento का उपयोग कर रहा है, हालांकि आपका पॉलीमोर्फिक भिन्नता प्रतीत होता है। पैटर्न पर विचार करें क्योंकि वे पैटर्न कैटलॉग में दिखाई देते हैं, जो कि अंतिम परिणाम के लिए आवश्यक प्रारंभिक बिंदु पर आधारित होते हैं। पैटर्न वहां बहुत ही प्रकृति होते हैं जिन्हें विस्तारित और संयुक्त किया जाना चाहिए।

Command pattern आपको कमिट और रोलबैक (डू/अंडो) दे सकता है और इसे इस तरह मेमेंटो के साथ जोड़कर एक आम दृष्टिकोण है। जावा Servlet API में HttpRequest & HttpResponse के साथ एक ही चीज़ देखी जाती है।