क्या मुझे एक फॉर्म पर सार्वजनिक / संरक्षित घटकों के लिए एक्सेसर विधियों / गेटर सेटर्स प्रदान करना चाहिए?

यदि मेरे पास एक घटक / ऑब्जेक्ट के साथ .NET फॉर्म है जैसे कि टेक्स्टबॉक्स जिसे मुझे किसी माता-पिता या अन्य रूप से एक्सेस करने की आवश्यकता है, तो मुझे स्पष्ट रूप से इस घटक को आंतरिक या सार्वजनिक स्तर चर के लिए संशोधक "अपग्रेड" करने की आवश्यकता है।

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

हालांकि, वीएस डिजाइनर उन सार्वजनिक वस्तुओं के लिए ऐसे गेटर्स / सेटर्स को लागू नहीं कर रहा है जो एक रूप में घटक हैं (और इसलिए अच्छे प्रोग्रामिंग अभ्यास का पालन नहीं करते हैं)।

तो, सवाल है; "सही चीज़" करने के लिए मुझे गेटटर और / या सेटर में ऐसे वीएस डिजाइनर घटकों या ऑब्जेक्ट्स को लपेटना चाहिए?

0
ro fr bn

4 उत्तर

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

मैं समझ नहीं पा रहा हूं कि "अच्छा प्रोग्रामिंग अभ्यास का पालन नहीं करता" का क्या मतलब है। माइक्रोसॉफ्ट विजुअल स्टूडियो (तेजी से ऐप विकास के लिए) पर सामान बनाने में आसान बनाने के लिए अच्छे प्रोग्रामिंग प्रथाओं के बहुत का उल्लंघन करता है और मुझे नियंत्रण के लिए गेटर्स / सेटर्स की कमी दिखाई नहीं देती है इस तरह के किसी भी सर्वोत्तम प्रथाओं का उल्लंघन करना।

0
जोड़ा

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

0
जोड़ा

यह ऑब्जेक्ट उन्मुख डिजाइन में encapsulation का एक उत्कृष्ट उदाहरण है।

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

एक परिपक्व समाधान में शायद निम्नलिखित डिज़ाइन बिंदु शामिल होंगे:

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

और यह यूनिट परीक्षण जैसी मेटा-डेवलपमेंट चीजों का भी उल्लेख नहीं कर रहा है।

0
जोड़ा

" हालांकि, वीएस डिजाइनर उन सार्वजनिक वस्तुओं के लिए ऐसे गेटर्स / सेटर्स को लागू नहीं कर रहा है जो एक रूप में घटक हैं (और इसलिए अच्छे प्रोग्रामिंग अभ्यास का पालन नहीं करते हैं)। "

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

डिजाइनर यहाँ सही काम करता है।

0
जोड़ा