M के बारे में और V के बारे में और C के बारे में थोड़ा

सुखद अप्रत्याशित के बीच की खबरों ने सभी प्रकार की यादों को जगाया, मीठा और ऐसा नहीं। मैं भी उससे इस लेख के लिए मिला, और तुरंत उदासीनता से बीमार हो गया, और मैं पिछले सात वर्षों में उससे इस तरह के वजनदार दीर्घवृत्त खेलना चाहता था।

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

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

और किसी भी सभ्य यूआई की तरह, यह काम किया, ज़ाहिर है, घटना मॉडल के अनुसार। बटन ऑब्जेक्ट में OnClick ने वह सब कुछ वर्णित किया है जो बटन करता है, एक पाठ क्षेत्र में प्रवेश करते समय OnChange, सब कुछ वयस्कों की तरह है। लेकिन इसके बाद - आगे, दुर्भाग्य से, अभी तक कुछ भी नहीं था।

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

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

और यहां तक ​​कि अगर यह बन गया है - इसके बारे में भूलना आसान है, यहां एक मन जाल है, जैसे उन ऑप्टिकल और ध्वनि भ्रम जिनके बारे में इंटरनेट पर जमकर बहस की जाती है। तो मुझे डेल्फी से यूआई की एक आधुनिक समझ के लिए एक छोटे से पुल को फेंकने की कोशिश करें और हम यह पता लगा सकते हैं कि क्या होता है।

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

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

और यदि आप एक सुंदर नई जेट दुनिया में रहते हैं, तो इस सभी ओओपी घटना-उपद्रव को देखते हुए, तो सिद्धांत एक ही रहता है: एक बटन दबाने से इसी क्रिया को जोड़कर अपनी स्थिति बदल जाती है, और फिर कुछ कोड, कोड नहीं होता है UI के तत्वों से जुड़े, इस क्रिया को देखें, और उचित निष्कर्ष निकालें, और स्थिति को बदलें ताकि UI बैक पर प्रदर्शित होने के लिए कुछ हो।

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

खैर, तब नियंत्रक, या प्रस्तुतकर्ता, प्रक्रिया को संसाधित करता है और परिणाम का उत्पादन करता है। उसे बुलाओ जैसे तुम आदी हो, बस किसी भी दृश्य तत्व को उसमें मत डालो।

लाभ क्या है? मैं सबसे स्पष्ट से सबसे अधिक क्रम में सूची देता हूं, मेरी राय में, आवश्यक।

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

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

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

दृश्य भाग और तार्किक को अलग करने से आपको लगता है कि, सबसे पहले, दृश्य भाग कैसे काम करता है: इसमें क्या आता है, इससे क्या होता है, क्या होता है अगर कुछ ऐसी चीज की उम्मीद की जाती है जो अंदर या बाहर आने की उम्मीद नहीं करती है। और नियंत्रण से अलग तर्क लिखना आपको इसे मामलों में लिखने के लिए मजबूर करता है, जो कि किसी विशेष स्थान पर किसी विशेष एप्लिकेशन का उपयोग करने के संभावित परिदृश्यों के अनुसार होता है, जिसमें प्रसंस्करण त्रुटियां भी शामिल हैं, और उपयोगकर्ता को यहां आने वाली कठिनाइयों में मदद करता है। खैर, हाँ, हमेशा नहीं, या बल्कि सब कुछ में नहीं, सामान्य रूप से एक समाधान एक विशेष मामले के लिए तैयार समाधान से बेहतर है।

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