वंशानुक्रम से क्यों बचा जाना चाहिए?


9

मुझे याद है कि VB4 सीखना और एक फॉर्म पर एक बटन खींचना, उस बटन पर डबल-क्लिक करना और उस ईवेंट हैंडलर में टाइपिंग कोड जो मैं अभी-अभी जादुई रूप से धन्य था। QBASIC I से "VB" में "V" के साथ रोमांचित था, दृश्य डिजाइनर सचमुच कटा हुआ ब्रेड के बाद से सबसे अच्छी बात थी।

बेशक आप यह सब प्रोग्रामेटिक रूप से कर सकते हैं लेकिन "वी" का जादू इतना आकर्षक था कि आप सिर्फ मदद नहीं कर सकते बल्कि उस बटन को खींच सकते हैं। हमें वह मार्ग अपनाने के लिए प्रोत्साहित किया गया।

लेकिन फिर कुछ साल पहले मैंने C # और .net फ्रेमवर्क के बारे में सीखना शुरू किया और जिस तरह से मुझे लगा कि मुझे पता था कि खिड़की से बाहर चला गया था, उस पर मोहित था। VB6 में बहुत सारा जादू चल रहा है जो कि पूरी तरह से .net में अनावरण किया गया है: कंस्ट्रक्टर ले लो और InitializeComponentsउदाहरण के लिए विधि। बाद में आपको टूलबॉक्स से खींचे गए सभी नियंत्रण उदाहरण मिल जाएंगे, आपके द्वारा पंजीकृत सभी ईवेंट और डिज़ाइनर में आपके द्वारा सेट किए गए गुण।

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

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

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

हम सभी सिर्फ आलसी नहीं हो सकते हैं, इसलिए मुझे क्या हिस्सा याद आ रहा है?


मुझे समझ नहीं आ रहा है। क्या आप यह समझ रहे हैं कि हमें दृश्य डिजाइनरों का उपयोग नहीं करना चाहिए और सभी जीयूआई कोड को हाथ से लिखना चाहिए?
बृहस्पतिवार

Pre .NET वह कोड कहाँ था जो फ़ॉर्म पर खींची गई सभी वस्तुओं को नियंत्रित करता था?
जेफ़ो

1
@JeffO ने जिस विरासत कोड से निपटा है, उसे देखते हुए, मैं सही-सही कहूंगा कि कहीं न कहीं एड-हॉक इनलाइन SQL और बिजनेस लॉजिक के बीच है। प्वाइंट है, WinForms है .net; इसलिए यदि डिजाइनर आजकल "खराब कोड" और "खराब कोडिंग की आदतों" की तरह महक रहा है और वास्तव में टूट जाता है जब आप चीजों को संरचित करना शुरू करते हैं, तो मैं कहता हूं कि डिजाइनर को ड्रॉप करें और रूपों का इलाज करें जैसे कि वे (कक्षाएं!) हैं। । और CJ में UI परत को कैसे कोडित किया जाता है? WinForms में ऐसा करना "थकाऊ" है क्योंकि "हे लुक एक डिज़ाइनर है"? क्या एक्सटीजेएस यूआई थकाऊ कोडिंग है?
मैथ्यू गुइंडन

मैं एक अन्य उपयोगकर्ता को उद्धृत करने जा रहा हूं: कोडकैस्टर; एक ईवेंट हैंडलर GUI को आपके व्यावसायिक तर्क से जोड़ने के लिए है। यदि आपके पास उपयोगकर्ता के नाम और ऐड बटन दर्ज करने के लिए एक टेक्स्टबॉक्स है, तो ऐड बटन पर क्लिक करके केवल _userRepository.AddUser (UsernameTextbox.Text) को कॉल करना चाहिए। आप इवेंट हैंडलर में व्यावसायिक तर्क नहीं चाहते हैं। stackoverflow.com/questions/8048196/…
Pieter B

@ पीटर अपनी प्रस्तुति परत में एक DAL निर्भरता डाल नहीं है?
मथिउ गुइंडन

जवाबों:


9

मैं आपको अलग-अलग प्रतिमान के साथ विरोध करने वाला हूं: विरासत पर अनुकूल रचना।

यहां तक ​​कि जब आप हाथ से GUI कोड लिखना शुरू करते हैं और रूपों के बीच व्यवहार और दृश्यों को साझा करने के लिए वंशानुक्रम का उपयोग करते हैं, तो आप सामान्य OOP डिज़ाइन के समान समस्या को मारेंगे। कहते हैं कि आपके पास डायलॉगफार्म है, जिसमें ओके / रद्द बटन और ग्रिडफार्म है, जिसमें ग्रिड है। आप DialogForm के सभी संवाद और ग्रिड से ग्रिड के साथ सभी रूपों को प्राप्त करते हैं। और तब आपको पता चलता है कि आप दोनों के साथ फॉर्म चाहते हैं। आप इसे कैसे हल करेंगे? यदि आप फॉर्म इनहेरिटेंस का उपयोग कर रहे हैं, तो इसका कोई तरीका नहीं है। दूसरी तरफ, यदि आप UserControls का उपयोग कर रहे हैं, तो आप बस अपने फॉर्म पर GridControl डाल सकते हैं और इसके साथ किया जा सकता है। और आप अभी भी UserControls के साथ डिज़ाइनर का उपयोग कर सकते हैं, इसलिए आपको थकाऊ GUI कोड लिखने में समय बर्बाद करने की ज़रूरत नहीं है।


अच्छी तरह से आधार फॉर्म में केवल पैनल 2 के साथ एक स्प्लिटकॉर्नर निर्धारित किया गया है, जिसमें एक फ्लो -आउटआउट पैनल होता है, जिसे BottomPanelसामान्य ओके / रद्द / लागू / बंद व्यवहार कहा जाता है और होस्ट करता है; पैनल 1 में पैनल 1 तय (सामान्य "निर्देश" लेबल, या मेनू, टूलबार, जो भी शीर्ष पर जाता है) के साथ एक स्प्लिटकोनेटर होता है और जिसे एक संरक्षित पैनल कहा जाता है MainContent। प्रत्येक वास्तविक कार्यान्वयन यह तय करता है कि इसे कैसे भरना है। सभी सामग्री को कार्यान्वयन में इंजेक्ट किया जा सकता है और हां, यह समय, अच्छी बात को बचाने के लिए डिजाइनर के साथ बनाया गया उपयोगकर्ता नियंत्रण हो सकता है .. लेकिन फॉर्म के बारे में क्या?
मैथ्यू गुइंडन

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

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

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

1
@ सुंदर: कौन सा डिजाइनर? हम डेल्फी का उपयोग करते हैं, और इसके डिजाइनर विरासत वाले रूपों के साथ ठीक काम करते हैं। और फिर, यदि आपके पास एक अच्छा डिज़ाइन है, तो आपके पास ये समस्याएं नहीं हैं । यदि आप कुछ भी योजना नहीं बनाते हैं, तो निश्चित रूप से यह सभी भंगुर होने वाला है और कभी भी आप इसे छूते हैं, लेकिन यह किसी भी अन्य कोड से अलग नहीं है।
मेसन व्हीलर

2

इसमें से अधिकांश पसंद के प्रौद्योगिकी ढेर से बंधा हुआ है।

WinForms और WPF दोनों .NET UI फ्रेमवर्क हो सकते हैं लेकिन अंतिम लक्ष्य को प्राप्त करने के तरीके में काफी भिन्नता है। कुछ प्रतिमान सिर्फ प्रौद्योगिकियों के बीच चलते हैं, लेकिन अन्य नहीं करते हैं और आपको कोशिश नहीं करनी चाहिए और प्रतिमान को केवल इसलिए मजबूर करना चाहिए क्योंकि आपको लगता है कि यह हर ढांचे में मौजूद है। एक कारण है कि MVVM WPF / SL पर आधारित है और MVC Web.NET और इसी तरह ASP.NET में एक अलग अवधारणा है। कुछ प्रतिमानों के साथ कुछ प्रौद्योगिकियां बेहतर काम करती हैं।

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


0

आप अपने क्षेत्रों को सही ढंग से संलग्न करने और तदनुसार आबादी प्रदान करने में विरासत का उपयोग कर सकते हैं। यदि आप वंशानुक्रम का उपयोग करने के इच्छुक थे, तो मेरा सुझाव आधार फॉर्म और उस फॉर्म के लिए संबंधित मॉडल होगा, और प्रत्येक व्युत्पत्ति के लिए फॉर्म और मॉडल दोनों प्राप्त होंगे।

एक बेहतर विकल्प एक से अधिक UserControl नियंत्रणों में समूह से संबंधित नियंत्रण होगा। संबंधित डेटा डालने के लिए आपको बस थोड़ा सा तर्क चाहिए।


0

मैं मेसन व्हीलर से पूरी तरह सहमत हूं, हालांकि तीन साल में शायद खुद भी अपना मन बदल लिया था।

मैं डेल्फी के निष्पादनयोग्य से WEB में प्रवास के लिए विकल्पों की तलाश करने की कोशिश कर रहा हूं।

अब तक मैंने खुद को UNIGUI के लिए तय कर लिया था, क्योंकि मैं अभी भी फॉर्म इनहेरिटेंस का उपयोग कर सकता हूं। मैं डेल्फी को डार्ट जैसे मिक्सिंस के रूप में पसंद करूंगा, क्योंकि इससे मेरे पूर्वजों के रूप कम होंगे। लेकिन मुझे लगता है कि लोग विज़ुअल फॉर्म इनहेरिटेंस की तुलना में MVC में बहुत अधिक कोड लिखते हैं, क्योंकि अधिकांश नेविगेशन, डेटामॉड्यूले (अप्लायडेट्स) में सत्यापन नियमों को कॉल करते हैं, एसक्यूएल फ़िल्टरिंग मानदंड, ग्राहक डेटासेट खोजते हैं, सब कुछ 5 में लिखा है 6 शायद 6 पूर्वजों का रूप।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.