कमांड डिजाइन पैटर्न - क्या Invoker वैकल्पिक है?

Question

कमांड डिजाइन पैटर्न में Invoker क्लास वैकल्पिक है? ग्राहक को कमांड के लिए कंक्रीट कमांड और रिसीवर को तुरंत चालू करने की आवश्यकता है। क्या ग्राहक को हमेशा Invoker को तुरंत चालू करने और Invoker ऑब्जेक्ट पर कमांड ऑब्जेक्ट को पास करने की आवश्यकता होती है। बाद में जब भी ग्राहक को आदेश निष्पादित करने की आवश्यकता होती है, क्लाइंट केवल Invoker ऑब्जेक्ट से पूछता है और Invoker कमांड करता है (शायद बाद में या बाद में निष्पादन के लिए आदेश कतारबद्ध कर सकता है)।

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

Answer 1

कमांड पैटर्न के उद्देश्य आमतौर पर 1) विभिन्न संचालन का एक सेट उसी प्रकार साझा करते हैं ताकि उन्हें उसी कोड द्वारा संसाधित किया जा सके 2) ऑपरेशन आमंत्रण से अलग ऑपरेशन मार्शलिंग/निर्माण। रेसीवर स्पष्ट रूप से उद्देश्य 2 के लिए आवश्यक है।

यदि आप सृजन के बाद सही आते हैं या यदि रेसीवर आवेदक की भूमिका निभा रहा है, तो कोई एकल उद्देश्य, स्टैंड-अलोन इनवॉकर नहीं है। इसका मतलब है कि कोई भी चालक वास्तव में दार्शनिक प्रश्न नहीं है :)

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

संपादित करें: मुझे लगता है कि एकल जिम्मेदारी सिद्धांत का तर्क है कि आपको उन्हें अलग करना चाहिए, लेकिन ऐसी बात है जो कमजोर समझ में आती है :) स्थानीय स्थितियां देखी जा सकती हैं और देखी जानी चाहिए।

Answer 2

जैसा कि हम जानते हैं, java.lang.Runnable कमांड पैटर्न के उदाहरणों में से एक है जहां थ्रेड क्लास एक आवेदक के रूप में काम करता है। हम एक रननेबल क्लास की ऑब्जेक्ट थ्रेड क्लास में पास करते हैं और स्टार्ट/रन कहते हैं।

लेकिन हम कभी क्लाइंट क्लास नहीं बनाते जो मुख्य धागे का आह्वान कर सकता है।

तो एक चालक वैकल्पिक नहीं है लेकिन यह कड़ाई से ग्राहक के साथ मिलकर नहीं है। तो कमांड पैटर्न का यूएमएल क्लाइंट क्लास और इनवॉकर क्लास के बीच कोई रिश्ते नहीं दिखाता है।

इस प्रश्न से संबंधित एक और answer।