क्या यह सोचकर आर्किटेक्चर डिजाइन करना अच्छा होगा कि यूजर इंटरफेस क्लासेज को कमांड लाइन इंटरफेस द्वारा बदला जा सकता है?

Question

कोड कम्प्लीट पेज 25 में कहा गया है कि कमांड लाइन वन द्वारा नियमित यूजर इंटरफेस कक्षाओं को आसानी से बदलने में सक्षम होना एक अच्छा विचार है।

परीक्षण के लिए इसके फायदे जानने के बाद, इसमें क्या समस्याएँ आ सकती हैं?

क्या यह अतिरिक्त कार्य वास्तव में वेब और मोबाइल परियोजनाओं के लिए भुगतान करेगा? लघु और मध्यम परियोजनाओं के बारे में क्या; क्या वही नियम लागू होते हैं? क्या होगा अगर यह आपके डिज़ाइन को अधिक जटिल बनाता है?

Comments

पर्ल में, यह सिर्फ MooseX :: Getopt और Plack :: हैंडलर :: CLI जैसे उपकरण हैं।

— ईथर

यदि आप अपने प्रोग्राम को पहले CLI के साथ बनाते हैं, तो UI को इसके शीर्ष पर स्तरित किया जा सकता है, जिससे प्रोग्राम में गहराई से एम्बेडेड UI की तुलना में अधिक लचीलापन मिलता है। यह वेब सेवाओं के लिए बहुत समान है।

— zzzzBov

हमेशा एक मजबूत शब्द है।

— मार्क कैनलास

कृपया मूल उद्धरण पर ध्यान दें, जो है: "आर्किटेक्चर को संशोधित किया जाना चाहिए ताकि कार्यक्रम के व्यावसायिक नियमों और आउटपुट भागों को प्रभावित किए बिना एक नया उपयोगकर्ता इंटरफ़ेस प्रतिस्थापित किया जा सके। उदाहरण के लिए, आर्किटेक्चर को इसे बंद करना आसान बनाना चाहिए। इंटरैक्टिव इंटरफ़ेस वर्गों का समूह और कमांड लाइन कक्षाओं के एक समूह में प्लग। " तो CC यह नहीं कहता है कि आपको GUI को एक कमांड लाइन के साथ बदलने के लिए तैयार करना चाहिए, यह सिर्फ यह कहता है कि आर्किटेक्चर को UI बदलने के साथ होना चाहिए। GUI-> कमांड लाइन चीज़ केवल एक उदाहरण है।

— साल्स्के

@ वांडेल I में कोड पूरा का दूसरा संस्करण है और यह पृष्ठ 25 पर उल्लिखित नहीं है। आप किस संस्करण का उल्लेख कर रहे हैं?

— JW01

Answer 1

विभिन्न इंटरफेस (जैसे GUI बनाम CLI बनाम REST) ​​के तहत कार्यक्षमता का पुन: उपयोग करने में सक्षम होना हमेशा आवश्यक नहीं होता है, लेकिन एक प्रणाली के लिए गंभीर पुन: उपयोग करने और सक्षम करने के लिए अच्छा होता है , क्योंकि अन्य लोग इसके साथ बातचीत करने के नए तरीके ढूंढते हैं।

इसमें कुछ कमियां हैं जिनका भार उठाने की आवश्यकता है:

1. इसके लिए अतिरिक्त अमूर्त परतों (कभी-कभी टियर) की भी आवश्यकता होगी। जबकि ये परतें अच्छी इंजीनियरिंग प्रैक्टिस हैं, उनके पास विकास में एक अतिरिक्त लागत है, यह समझना कि अन्य क्षेत्रों (जैसे रखरखाव, पुन: उपयोग, परीक्षण) में प्रयास को कम करने के लिए नेतृत्व नहीं किया जा सकता है इसलिए यह इसके बारे में थोड़ा विचार करने के लिए लायक है।
2. एक माध्यम के लिए इष्टतम प्रवाह दूसरों के लिए भयानक हो सकता है। यदि कार्यक्षमता को GUI का समर्थन करने के लिए डिज़ाइन किया गया था, तो यह वेब के लिए बहुत अधिक चैट हो सकता है । सभी माध्यमों में सभी कार्यक्षमता सार्थक नहीं है।
3. सेवाओं और उपयोगकर्ता इंटरफ़ेस के बीच एक सामान्य कनवर्टर को परिभाषित करने की कोशिश में एक जाल है, इसलिए कोई भी सेवा अनुबंध को परिभाषित कर सकता है और सभी माध्यमों के लिए स्वचालित रूप से (या जितना संभव हो) UI प्राप्त कर सकता है। कई परियोजनाओं ने इस तरह के ढांचे के निर्माण और आवश्यकताओं में बदलाव के रूप में हर संभव अनुकूलन को जोड़ने के प्रयास में बहुत अधिक बर्बाद किया।

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

Comments

जैसा कि अन्य टिप्पणियों में कहा गया है, इसे कोड सामंजस्य बढ़ाना चाहिए और युग्मन को कम करना चाहिए। इन दोनों को आपके कोड को सरल और परीक्षण करने में आसान बनाना चाहिए। प्रवाह एक GUI अवधारणा अधिक है, और आमतौर पर अन्य कार्यक्षमता में मौजूद नहीं होना चाहिए।

— BillThor

मेरा मानना ​​है कि यह अभी तक उल्लेख नहीं किया गया है, लेकिन यह मॉडल-व्यू-कंट्रोलर आर्किटेक्चर का सार है। बिंदु को @BillThor के अनुसार युग्मन को कम करने के लिए, विचारों और नियंत्रकों को स्वैप करने में सक्षम होना है। यह एमवीसी के लिए सबसे अच्छा उपयोग मामला है।

— रुडोल्फ ओलह

Answer 2

पूरी तरह से परीक्षण से अलग, इस दृष्टिकोण का स्पष्ट लाभ यह है कि यह आपकी परियोजना को स्वचालित और स्क्रिप्ट योग्य बना देगा । अगर मैं एक प्रोग्राम में कमांड-लाइन कमांड भेजने में सक्षम हूं, तो मैं जटिल कार्य करने के लिए एक स्क्रिप्ट लिख सकता हूं बहुत आसानी से (और मज़बूती से!) जितना मैं एक जीयूआई पर एक ही चीज़ को स्वचालित करने के लिए एक मैक्रो बना सकता हूं।

वास्तव में ऐसा करने लायक है या नहीं, यह पूरी तरह से इस बात पर निर्भर करता है कि आपके पास बहुत सारे उपयोगकर्ता हैं या नहीं, जो आपके कार्यक्रम को स्वचालित करना चाहते हैं।

Comments

बहुत सारे एप्लिकेशन स्क्रिप्टिंग के लिए एक प्लगइन मॉडल का उपयोग करते हैं। आमतौर पर ऑब्जेक्ट मॉडल को उजागर किया जाता है और स्क्रिप्ट लिखने के लिए अजगर जैसी भाषा का उपयोग किया जाता है। मुझे नहीं लगता कि कमांड लाइन पैरामीटर गैर-तुच्छ ऐप के लिए काम करेगा।

— सॉफ्टवेयड

एक और लाभ खोजी जा सकता है। उदात्त पाठ की Ctrl-Shift-P विशेषता इसका एक शानदार उदाहरण है। अगर कुछ अस्पष्ट कार्यक्षमता है, जो मुझे मेनू के माध्यम से खोजना है, तो मैं केवल यह लिखता हूं कि मुझे लगता है कि इसे कहा जाएगा, और मैं कमांड (और शॉर्टकट) देख सकता हूं और इसे तुरंत निष्पादित करने में सक्षम हूं।

— एडम इले

OpenDJ, एक खुला स्रोत, जावा आधारित LDAP सर्वर इसका एक शानदार उदाहरण है: GUI में आपके द्वारा किए जाने वाले प्रत्येक संशोधन की कमांड लाइन पुष्टिकरण संवाद बॉक्स में उपलब्ध है।

— फ्रेंक

@ Marnixv.R .: इशारे केवल कुछ कार्य करने के लिए एक सुविधाजनक तरीका है जो एक कमांड द्वारा निर्दिष्ट किया जा सकता है, जैसे '35.73N 118.23W पर ज़ूम'। एक ड्राइंग कमांड के रूप में इनपुट हो सकता है, हालांकि यह असुविधाजनक होगा। फिर भी मुझे लगता है कि सुविधापूर्ण रूप से स्क्रिप्ट योग्य इंटरफ़ेस में बहुत उपयोगिता है, और एक को बनाने के लिए बहुत कम श्रम की आवश्यकता होती है।

— केविन क्लाइन

+1: एक अन्य महत्वपूर्ण लाभ यह है कि उपयोगकर्ता की क्रियाओं को लॉग करना आसान बनाता है, उत्पादन समस्याओं के प्रजनन को सरल बनाता है।

— केविन क्लाइन

Answer 3

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

Comments

-1 कई पूरी तरह से गलत बयानों के लिए। बेशक यह इसे और अधिक जटिल बना देगा। यह सब के बाद, एक अतिरिक्त आवश्यकता / सुविधा है।

— बोरिस यांकोव

@BorisYankov मुझे लगता है कि उनका मतलब "जटिल" के बजाय "जटिल" था - वे समान ध्वनि करते हैं और अर्थ में ओवरलैप करते हैं, इसलिए वे इस अवसर पर भ्रमित करना आसान है

— इज़काता

Answer 4

एक प्रमुख लाभ जिसका उल्लेख नहीं किया गया है वह यह है कि ऐसा करने में सक्षम होना अंतर्निहित कोड से UI के सख्त डिकॉउपिंग को लागू करता है । इसका एक प्रमुख लाभ यह है कि इसका अर्थ है कि यदि आपको GUI को बदलने की आवश्यकता है (जैसे iOS मानकों को OSX मानकों या किसी अन्य के लिए एक ग्राफिकल इंजन के रूप में कहें), तो यह सब आपको बदलना होगा, क्योंकि अंतर्निहित कोड पर निर्भर नहीं है UI का लेआउट। यह नहीं हो सकता, क्योंकि अगर यह होता तो कमांड लाइन टूल काम नहीं करता।

इसके अलावा, परीक्षण को स्वचालित करने में सक्षम होना एक महत्वपूर्ण लाभ है।

Comments

अगर मैं गलत हूं तो मुझे सुधारें, लेकिन एक जीयूआई से दूसरे में बदलने के बाद भी फॉर्म वैधीकरण / त्रुटि संदेश दिखाने, ईवेंट हैंडलर सेट करने आदि के संदर्भ में महत्वपूर्ण काम की आवश्यकता होगी

— अपवोट

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

— ओसाद

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

— क्लिक करें

@ClickUpvote एक हद तक यह निर्भर करता है कि आप अपने GUI को कैसे लागू करते हैं। एक बहुत ही पतली GUI जो सिर्फ वैल्यू चेंज किए गए मैसेज को एक सपोर्ट क्लास को भेजती है और जवाब में ValueValid / ValueInvalid मैसेज प्राप्त करती है, जो कि ऑनटेक्स्टबॉक्स चेंज किए गए ईवेंट्स में सभी वैरिफिकेशन को अंजाम देना आसान हो जाएगा।

— डैन नीली

@ClickUpvote मैं काफी सहमत हूं, इसीलिए मैं उस चीज़ पर ध्यान केंद्रित करने में सक्षम होना चाहता हूं जो मुझे पसंद नहीं है, या मैं इस बात को ध्यान में रखूं कि मुझे अपने पूरे ध्यान से नफरत है, इसलिए मैं जल्द से जल्द इसके साथ हो सकता हूं।

— डेवार्डे

Answer 5

हाँ यह लगभग हमेशा एक अच्छा विचार है।

यदि आप इस दृष्टिकोण का पालन करते हैं, तो आपके पास GUI के रूप में एक ही थ्रेड में व्यावसायिक तर्क या डेटा एक्सेस और कुछ GUI हैंडलर के पीछे होने की संभावना नहीं होगी। यह कारण अकेले निवेश करने लायक है।

Comments

यदि आप एक पाठ संपादक जैसे लिख रहे हैं, तो इसका क्या फायदा होगा?

— nikie

@nikie क्योंकि, उदाहरण के लिए, आप अपने WYSIWIG टेक्स्ट एडिटर दृश्य को एक सादे टेक्स्ट या मार्कअप आधारित फ्रंट-एंड से बदल सकते हैं, और जब तक यह अंतर्निहित मॉडल को एक ही जानकारी देता है, तब तक आपका मौजूदा इन्फ्रास्ट्रक्चर काम करना जारी रखेगा।

— डेवॉर्ड

Answer 6

मुझे लगता है यह एक अच्छा विचार है। इसके अलावा एक दूसरा, कमांड लाइन फ्रंट एंड लिखने में सक्षम होने के नाते, अंततः साबित होता है कि व्यापार तर्क किसी विशेष एप्लिकेशन सर्वर आर्किटेक्चर के लिए पूरी तरह से डिकोड हो गया है।

Answer 7

ऐसा करने में मुझे जो एकमात्र खतरा दिखाई देता है, वह यह है कि यूआई में एक निश्चित भाग को प्राप्त करने के लिए, उपयोगकर्ता को आमतौर पर यूआई के अन्य भागों को पार करना पड़ता है।

जहां डेवलपर सिर्फ यूआई को सीधे निष्पादित कर सकता है। मैंने ऐसी परिस्थितियाँ देखी हैं जहाँ एक डेवलपर तब तक उपयोगकर्ताओं की समस्या को पुन: उत्पन्न नहीं कर सकता था जब तक कि वे वास्तव में उत्पाद का उपयोग नहीं करते हैं।

इतना कारक कि परीक्षण बनाते समय भी।

Answer 8

नहीं, सलाह के भयानक बिट।

यह थोड़ा याग्नी है (आपको इसकी आवश्यकता नहीं है)।

कमांड लाइन इंटरफ़ेस को एक्सपोज़ करना एक तरह से आपके ऐप को संरचित करने के समान नहीं है जो यूनिट टेस्टिंग का समर्थन करता है, या एसओएलआईडी के किसी भी हिस्से का अनुपालन करता है, या मैं जो भी प्रोग्रामिंग प्रैक्टिस की सिफारिश करता हूं।

यह किसी भी यूआई के लिए काम नहीं करता है जो सिर्फ कमांड लाइन इंटरफेस के अनुरूप नहीं होगा। एमएस पेंट एक बहुत ही सरल ऐप है, लेकिन कैसे, किसी भी स्थिति में, क्या आप कमांड लाइन से इसे नियंत्रित करने में सक्षम होने के लिए एक लाभ देखेंगे?

यह आपको स्क्रिप्टिंग को लागू करने में मदद नहीं करेगा। यह वास्तव में उस दिशा में किसी भी प्रगति में बाधा होगी।

एकमात्र सकारात्मक बात यह है कि यह पृष्ठ 25 पर दिखाई देता है, इसलिए कम से कम आपको एक चेतावनी मिलती है कि शेष पुस्तक हो सकती है, ... बदबूदार। मैंने इसे बहुत पहले पढ़ा था और मुझे यह पसंद नहीं आया, इसलिए मैं पक्षपाती हूं।

Comments

सहमत [phone]

स्क्रिप्ट योग्य MSPaint वास्तव में वास्तव में उपयोगी लगता है।

— राउंडटॉवर

IMO सबसे अच्छा जवाब। जब से मैं "YAGNI 'को लागू नहीं करता हूँ" मंत्र का पालन करता हूं, मेरे पास वास्तविक कार्य पर ध्यान केंद्रित करने के लिए अधिक समय है और मेरे पास अभी भी बहुत समय बचा है। अग्रिम रूप से चतुर होने की कोशिश ने मुझे दिखाया है कि अधिकांश समय ग्राहक पहले बताए गए समय की तुलना में कुछ अलग विस्तार चाहते थे, इसलिए किसी भी चीज पर समय बर्बाद नहीं करना चाहिए।

— टॉपस्किप

PSPaint + कमांड लाइन इंटरफ़ेस = ऑटोकैड

— वोरैक

-1 (अगर मैं कर सकता था) ध्यान दें कि यह नहीं कहता है "एक सीएलआई लागू करें और साथ ही एक जीयूआई"; यह कहता है "एक CLI की तरह एक वैकल्पिक UI को लागू करने के लिए पूरा करें"।

— मार्क हर्ड

Answer 9

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

यह परीक्षण में विशेष रूप से उपयोगी है।

एक व्यावहारिक उदाहरण देने के लिए, यदि मैं किसी एप्लिकेशन पर स्वचालित परीक्षण चलाना चाहता हूं, तो मैं एप्लिकेशन को स्वचालित रूप से इंस्टॉल करना चाहता हूं। ऐसा करने के लिए, मैं निम्नलिखित मानकों में पारित कर सकता हूं, "myApplication.exe / silinstall"।

मैं इसे प्रोग्राम कर सकता हूं ताकि जब मैं इस कमांड-लाइन स्विच को निर्दिष्ट करूं, तो GUI इंस्टॉलर के बिना, पृष्ठभूमि में चुपचाप एक इंस्टॉल किया जाता है। इंस्टॉलर के किसी भी इनपुट (जैसे कि इंस्टॉलेशन डायरेक्टरी) को शायद XML फाइल से उठाया जा सकता है।

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

कुछ अनुप्रयोगों में कमांड-लाइन स्विच होते हैं जो एक एप्लिकेशन को कुछ विकल्पों के साथ खोलने के लिए निर्दिष्ट करते हैं (उदाहरण के लिए, मैं अधिकतम विंडो में एप्लिकेशन को खोलने के लिए '/ मैक्सिमम' का उपयोग कर सकता हूं)।

ऐसे बहुत से परिदृश्य हैं जहाँ कमांड-लाइन इंटरफ़ेस उपयोग में आ सकता है। ये तो कुछ उदाहरण मात्र हैं।

Answer 10

वाक्यांश को फिर से नोटिस करें: "[यह]] एक अच्छा विचार है कि कमांड लाइन वन द्वारा नियमित उपयोगकर्ता इंटरफ़ेस कक्षाओं को आसानी से बदलने में सक्षम हो"। इसका मतलब यह नहीं है कि आपको सीएलआई लिखना होगा, बस आप इसे आसानी से कर सकते हैं।

तो, यह क्या कहता है कि आपके यूआई को बाकी कोड से अलग करना चाहिए।

Comments

मुझे लगता है कि आप एक टिप्पणी करने का इरादा रखते हैं, है ना?

— जूलियो रॉड्रिक्स

Answer 11

यह निर्भर करता है और जब मैं कहता हूं कि यह निर्भर करता है, यह सिर्फ एक जोड़े के मामले होने की बात नहीं है, बल्कि यह एप्लिकेशन और लक्षित दर्शकों पर बहुत निर्भर है। यह मानते हुए कि हम समीकरण से गेम को समाप्त कर रहे हैं तब भी आवेदनों की एक विस्तृत सरणी है जो आप लिख सकते हैं जहां एक कमांड जैसी संभावना नहीं है या कभी भी लागू नहीं होने वाली है। मेरे सिर के ऊपर, मोबाइल (जैसे iOS, Android, आदि) को लक्षित करने वाला कोई भी वातावरण इस शीर्षक के अंतर्गत आने की संभावना है।

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

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

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

Comments

मैं सामान्य रूप से असहमत नहीं हूं, लेकिन माया की एक बड़ी ताकत यह है कि यह वास्तव में एक बहुत मजबूत स्क्रिप्टिंग एपीआई (मूल रूप से MELScript, अब पायथन) है।

— jwd

@jwd - माया एक ऐसा उदाहरण है जिसे मैंने चुना है क्योंकि मैंने इसे कुछ साल पहले इस्तेमाल किया था, अगर आपके पास एक ही लाइन में एक बेहतर विचार है तो मुझे बताएं। हो सकता है कि ब्रायस हालांकि यह उतना अच्छी तरह से नहीं जानता हो?

— rjzii

Answer 12

निर्भर करता है।

अक्सर हम अपने कार्यक्रमों को मॉडल / व्यू / कंट्रोलर या मॉडल / व्यू / व्यू / मॉडल के रूप में विभाजित करते हैं। ऐसा लगता है कि मॉडल को कमांड लाइन एक्सेस की अनुमति देनी चाहिए, लेकिन मैं नियंत्रक के बारे में सुनिश्चित नहीं हूं। स्वाभाविक रूप से, दृश्य वह है जो प्रतिस्थापित किया जा रहा है।

कुछ अंतर उपकरण श्रृंखला के आधार पर मौजूद हो सकते हैं। कोड कम्पलीट एक Microsoft प्रेस पुस्तक है, इसलिए शायद आप इस GUI के लिए Microsoft तकनीकों का उपयोग कर रहे हैं? यदि ऐसा है, तो मुझे लगता है कि जब आप COM या DCOM के माध्यम से इंटरफेस को उजागर करने के लिए ऐप बनाते हैं तो एक चेक बॉक्स हो सकता है। कुछ Microsoft तकनीकों के लिए, मुझे लगता है कि संसाधन तालिकाओं और संदेश पासिंग बहुत गहन रूप से किसी भी चीज़ के साथ युग्मित हैं जो विज़ार्ड्स आपको तेजी से प्रोटोटाइप में मदद करते हैं। मुझे लगता है कि यह बेहतर हो रहा है, लेकिन अगर आप एमएफसी या फॉर्म बनाए रख रहे हैं, तो यह थोड़ा नुकसान पहुंचा सकता है।

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

मुख्य बिंदु मुझे लगता है कि सुझाव एक नियम नहीं है। यदि आप इसका पालन करते हैं, तो आपको आसान इकाई और स्वीकृति परीक्षण या फ़ॉल बैक इंटरफ़ेस प्राप्त करना चाहिए जब आप या ग्राहक क्लिक करने के बजाय टाइप करना पसंद कर सकते हैं। यदि यह स्वयं के लिए भुगतान करता है, तो इसे करें। सौभाग्य।

Comments

-1: कोड कंप्लीट प्रोग्रामिंग क्राफ्ट के बारे में एक भाषा-अज्ञेय पुस्तक है।

— डेवॉर्डे

उसने अन्यथा कभी नहीं कहा।

— Upvote

और उनका सवाल यूआई विकास के लिए विशिष्ट था ... आपकी बात मिस्टर डेवॉर्ड?

— इयान

Answer 13

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

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

Comments

मैप पर रूट की साजिश रचने वाला खुद को CLI ऑटोमेशन के लिए उधार क्यों नहीं देता? कुछ ऐसा है जो PlotRoute(startPoint, endPoint)बहुत सीधा है।

— मेसन व्हीलर

@MasonWheeler - मेरा मानना ​​है कि यह अधिक होगाPlotRoute(startPoint, endPoint, chart)

— फैब्रिकियो

Answer 14

इन दिनों (कम से कम जावा के लिए) ऐसा लगता है कि जितनी जल्दी या बाद में सभी प्रोग्राम एक वेब सेवा (SOAP या Ajax या दोनों) को जल्दी या बाद में जोड़ते हैं। तो सामान्य तौर पर हाँ ऐसा ही लगता है लेकिन अगर आप एक बेहतर मानसिक रूपक चाहते हैं तो वेब सेवा का फ्रंट एंड कमांड लाइन की तुलना में अधिक संभावना है ... और अधिक संभावना है।

Answer 15

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

जॉब्स के Apple में आने से पहले, बहुत परिष्कृत आवाज नियंत्रण तंत्र का पता लगाया जा रहा था। Apple ने सिरी जैसी चीजों के पक्ष में इसे दरकिनार कर दिया।

आह।

लोकप्रिय और स्पष्ट हमेशा "सर्वश्रेष्ठ" नहीं होते हैं।

Comments

कमांड लाइन के मुख्य कारणों में से एक मुख्य रूप से सॉफ्टवेयर की कार्यक्षमता का परीक्षण और स्क्रिप्ट करने में सक्षम होना है। यह सिर्फ सॉफ्टवेयर का परीक्षण करने या बैच स्क्रिप्ट चलाने के लिए हमारी आवाज़ की ऑडियो क्लिप रिकॉर्ड करने के लिए थोड़ा अजीब (या कम से कम डिस्क-हॉगि) प्राप्त कर सकता है।

Answer 16

यह आमतौर पर एक अच्छा विचार है, हाँ।

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

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

---

मैंने एक बार ब्राउजर में एक ड्रैगनेन यूआर रूपक प्रोग्राम किया था। UX को स्वाभाविक महसूस कराने के लिए बैक-एंड पर बहुत ही जटिल इंटरैक्शन नियम । मैंने साइट को एपीआई बनाकर इसे हल किया और जीयूआई एक पूर्ण ऐप था जो कार्रवाई पर घटनाओं को उत्पन्न करता था। एक मॉड्यूल ने इन घटनाओं को पकड़ा और एक टाइमर पर, उन्हें 'एपीआई कॉल' (नेटवर्क दक्षता के लिए) में बंडल किया।

परिणाम पूरी तरह से RESTful कोर सिस्टम था। दूसरी बात यह थी कि मेरे पास 3 पार्टियों के लिए एक इंटरफ़ेस था, जिसे मैं बिजनेस मॉडल के अनुसार संबद्धता प्रोफाइल का उपयोग कर सकता था।

Answer 17

एक फायदा यह है कि आप उपयोगकर्ता के दृष्टिकोण से यूआई के प्रवाह के बारे में सोचने के लिए मजबूर होंगे। (मैं क्या हासिल करने की कोशिश कर रहा हूं? मुझे किस संदर्भ को स्थापित करने की आवश्यकता है? उस संदर्भ को देखते हुए, मैं लक्ष्य कैसे प्राप्त करूं)

"बैंक खाता बनाएँ" और "एमएस वर्ड दस्तावेज़ लिखें" के बीच एक बड़ा अंतर है। यहां तक ​​कि अगर आप एक सीएलआई का निर्माण नहीं करते हैं, तो यह केवल "सीएलआई संदर्भ" पर विचार करने के लिए मूल्य जोड़ सकता है। मॉडल सिर्फ व्यापार वस्तु मॉडल में नहीं रहते हैं!