क्या बेहतर दिखाना () + छिपाना () या सेटविज़ुअल (बूल दिखाई देना) है?

Question

क्या बेहतर है और क्यों? (इंटरफ़ेस-डिज़ाइन बिंदु से):

क) दो Show()और Hide()कार्य करने के लिए

बी) एक SetVisible(bool visible)समारोह है

EDIT: उदाहरण के लिए कुछ ऑब्जेक्ट में दृश्यता की स्थिति होती है और इसे बदलने के लिए इस फ़ंक्शन का उपयोग किया जाता है।

ग) सभी तीन करवाने के लिए Show(), Hide(), SetVisible(bool visible)कार्यों

Comments

किस संदर्भ में? आम तौर पर इससे कोई फर्क नहीं पड़ता

— अवीव कोहन

meta.programmers.stackexchange.com/questions/6483/…

— gnat

उन सभी को सार्वजनिक क्यों नहीं किया गया है? ऐसे मामले हैं जहां आप जानते हैं कि उन्हें हमेशा दिखाया जाएगा या छिपाया जाएगा और ऐसे मामले हैं जहां आप सशर्त रूप से दिखाना या छिपाना चाहेंगे।

— मार्ली

@ उत्तोलक: Thats शायद बहुत अच्छी बात है।

— user3123061

जावा में, यह शुरुआती अपरकेस अक्षर के बिना सेटविजिबल, हाइड और शो होगा।

— पियरे अरलाउड

Answer 1

मैं पसंद करता हूं SetVisible(bool visible), क्योंकि यह मुझे क्लाइंट कोड इस तरह लिखने देता है:

SetVisible(DetermineIfItShouldBeVisible());

लिखने के बजाय

if (DetermineIfItShouldBeVisible()) {
    Show();
} else {
    Hide();
}

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

void ButtonWithALabel::SetVisible(bool visible) {
    myButton.SetVisible(visible);
    myLabel.SetVisible(visible);
}

Comments

समान रूप से, आप विज़िबल को एक संपत्ति भी बना सकते हैं, यह मानते हुए कि आपकी भाषा इसका समर्थन करती है। MyObject.Visible = false;मुझे के रूप में एक और भी अधिक सहज ज्ञान युक्त से हमलोंMyObject.SetVisible(false);

— ब्रायन

@ मेरे लिए यह कम पठनीय और डीबग करने योग्य है, क्योंकि यह प्रोग्राम व्यवहार को मेरी आंखों में छिपा देता है - अंतर्निहित विधि कॉल - लेकिन यह एक और कहानी है। जावा उस सिंटैक्स का समर्थन नहीं करता है, वैसे भी यह वरीयता और आंखों के प्रशिक्षण की बात है।

— इग्निस

SetVisible()सुझाव नहीं है (मेरे लिए) कि आप वास्तव में कुछ भी प्रदर्शित कर रहे हैं। यह अधिक पढ़ता है जैसे कि आप किसी वस्तु की दृश्यता गुण को निर्धारित कर रहे हैं, संभवतः इस गुण को मानने या छुपाने के लिए निर्धारित करने के लिए इस गुण के मान को जाँचने के लिए इसे संगत Refresh()या Redisplay()विधि पर छोड़ रहे हैं ।

— टीएमएन

दुर्भाग्य से जावा सी # की तरह गुणों का समर्थन नहीं करता है, केवल गेटर्स और सेटर्स जो आप ऊपर देखते हैं।

— द गिरीकैबेज

@ टीएमएन: मैं उम्मीद करूंगा कि दृश्यता को रोकने वाले अन्य कारकों की अनुपस्थिति में (जेड ऑर्डर, पैरेंट विजिबिलिटी, लोकेशन, आदि) setVisible(true)गति में एक ऐसी प्रक्रिया स्थापित करेगा , जहां सिस्टम अगले निष्क्रिय होने पर वस्तु खींची जाएगी, यदि पहले नहीं। मैं उम्मीद करूंगा कि refreshवस्तु के प्रदर्शन को जल्दबाजी करने के लिए उपयोगी हो सकता है, लेकिन यह कि वस्तु आखिरकार बिना किसी कारण के खींची जाएगी (जब तक कि इसकी दृश्यता falseउस समय से पहले सेट नहीं हो जाती)।

— सुपरकैट

Answer 2

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

संपत्तियों का समर्थन करने वाली भाषाओं में, इन्हें प्राथमिकता दी जानी चाहिए लेकिन चूंकि जावा और न ही सी ++ करते हैं, मुझे लगता है कि यह एक मूट बिंदु है।

मुझे लगता है कि setVisible()इन कारणों से प्राथमिकता दी जानी चाहिए:

1. यह तुरंत स्पष्ट है कि उलटा फ़ंक्शन क्या है। setVisible(false)आप रिवर्स कॉल करने के लिए setVisible(true)जबकि विपरीत hide()आसानी से हो सकता है reveal()।
2. जब भी आप यह निर्धारित कर रहे हैं कि यह कोड में किस राज्य को लेना चाहिए, तो आप प्रोग्रामेटिक रूप से सरल हो सकते हैं, यानी आप स्टेटमेंट setVisible(wantToSee)का उपयोग करने के बजाय कॉल कर सकते हैं if।
3. एक बार जब आपके पास कई समान कार्य होते हैं तो setX()प्रारूप सामान्य हो जाता है ताकि आपके पास लगातार कार्यों का एक सेट हो सके, जबकि क्रियात्मक दृष्टिकोण कार्यों के एक मेजबान को पैदा करता है जो यह पता लगाने में मुश्किल हो सकता है कि क्या आप नहीं जानते कि आप क्या देख रहे हैं। एपीआई में संगति उन्हें सीखने और याद रखने में काफी आसान बनाती है।

Comments

C ++ में गुण नहीं हैं, लेकिन इसमें नि: शुल्क फ़ंक्शन हैं, इसलिए आप नए सदस्य कार्यों को जोड़ने के बिना क्लास इंटरफ़ेस को बढ़ा सकते हैं, अर्थात युग्मन की कम डिग्री के साथ।

— डेट्रेललाइन

क्यूटी अक्सर तीनों को एक सुविधा के रूप में प्रदान करता है ताकि छिपाना () और शो () सिग्नल / स्लॉट सिस्टम का उपयोग करके अन्य घटनाओं से सीधे जुड़ा जा सके। यह वास्तव में स्लॉट सिस्टम की एक सीमा है, हालांकि - अगर यह बढ़ावा देने जैसे कुछ का उपयोग कर रहा है :: कार्य, सही / गलत तर्क कॉलबैक स्थापित करने के बिंदु पर बाध्य हो सकता है।

"जिन भाषाओं में गुणों का समर्थन किया जाता है, उन्हें प्राथमिकता दी जानी चाहिए लेकिन चूंकि जावा और न ही सी ++ करते हैं, मुझे लगता है कि यह एक लूट बिंदु है।" जरुरी नहीं। पाने के लिए / बसने वालों की प्राथमिकता में? हाँ। लेकिन set_v अदृश्य वास्तव में एक सेटर नहीं है।

— मील्स राउत

Answer 3

यह इस बात पर निर्भर करता है कि संदर्भ में क्या दिखाना और छिपाना है । पहले आप यह पता लगाना चाहते हैं कि आपका "मुख्य तरीका" कौन सा है, और इसे विकसित करने पर ध्यान दें:

• चुनने के कारण setVisible(bool)
  • यह केवल एक साधारण बिट-फ्लिप है, या आपकी वस्तु मुख्य रूप से राज्य धारण कर रही है
  • आपका उद्देश्य अपना अधिकांश समय CRUD के ढांचे में बिताना है
  • दिखाने और छिपाने के बीच बहुत आसानी से साझा कोड है
• लेने के कारण show()औरhide()
  • एक महत्वपूर्ण साइड-इफेक्ट या बहुत सारे तर्क चल रहे हैं, जैसे कि जब वस्तु को अपने दृश्यता राज्य के लिए अपने सभी कंटेनरों की जांच करनी होती है, या एक संक्रमण एनीमेशन को ट्रिगर करता है।
  • क्या यह एक डोमेन मॉडल का हिस्सा है जहां आशय व्यक्त करना महत्वपूर्ण है

ठीक है, तो अब जब आपने "सोने के मानक" के कोड को कोड कर दिया है, तो आपको यह पता लगाने की आवश्यकता है कि क्या यह अन्य शैली में पतली सुविधा-विधियों को जोड़ने के लायक है, जो कि जीवन को आसान बनाने के लिए जो कि आपके ऑब्जेक्ट का उपयोग करने जा रहा है।

• की सुविधा setVisible(bool)
  • यदि आप उन बयानों से बचते हैं जो तुच्छ स्थिति हैं और केवल दृश्यता को प्रभावित करते हैं (उदाहरण के लिए setVisible(a==b))
  • कुछ गेट्टर / सेटर फ्रेमवर्क में वायर्ड किया जा सकता है, अगर ऐसा हो तो किसी दिन आप होने की उम्मीद करें
• की सुविधा show()औरhide()
  • प्रथम श्रेणी के कार्यों और कॉलबैक (पूर्व onSuccess(widget.show)) वाली भाषा में उपयोगी
  • स्टैक-ट्रैस और प्रदर्शन प्रोफाइलिंग के साथ पढ़ना बहुत आसान है, क्योंकि आप जल्दी से देख सकते हैं कि कार्यक्रम क्या करने की कोशिश कर रहा था

TLDR: पता करें कि कौन सा सबसे महत्वपूर्ण है, इसे लागू करें, और फिर अपने आप से पूछें कि क्या यह दूसरी शैली को पतली सुविधा विधियों के रूप में जोड़ने के लायक है।

Answer 4

मैं कहूँगा "तीनों"।

Show()और Hide()से grok करने के लिए आसान हो जाते हैं SetVisible(true)और SetVisible(false)। हालाँकि, जब आप दृश्यता को तार्किक रूप से सेट करना चाहते हैं, तो बेहतर है कि आप इसके आसपास boolनिर्माण करने के बजाय एक विधि अपनाएं ।ifbool

बिना तर्क और न्यूनतम बॉयलरप्लेट के नकल के आप तीनों का समर्थन कर सकते हैं:

void Show() {
    foo.Show();
    bar.Show();
}

void Hide() {
    foo.Hide();
    bar.Hide();
}

void SetVisible(bool visible) {
    if (visible) {
        Show();
    } else {
        Hide();
    }
}

वैकल्पिक रूप से, यदि आपके द्वारा SetVisibleलपेटी जा रही चीजें अधिक- एपीआई एपीआई हैं:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

void SetVisible(bool visible) {
    foo.SetVisible(visible);
    bar.SetVisible(visible);
}

Comments

Microsoft प्रारंभ और रोकने के लिए इस दृष्टिकोण का उपयोग करता है System.Windows.Forms.Timer। व्यक्तिगत रूप से, मुझे यह भ्रामक लगता है। जब मैं दोनों को देखता हूं Showऔर SetVisible, मेरा पहला झुकाव आश्चर्य होता है कि क्या दोनों कार्यों के बीच कुछ महत्वपूर्ण अंतर है।

— ब्रायन

आप आसानी से उन्हें उस भ्रम को खत्म करने के लिए आसानी से प्रलेखित कर सकते हैं। मैं नहीं था क्योंकि यह एक सरल उदाहरण था।

— गैरी शट्लर

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

— ब्रायन

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

— अल्फ्रेडोकाडो

@AlfredoCasado मैं सहमत हूँ। क्या होगा अगर सेटविजियल को संरक्षित किया गया था ? आप इसे एक उपवर्ग से एक्सेस कर सकते हैं, लेकिन इस इंटरफ़ेस के साथ किसी दिए गए निकाय को कॉल कर सकते हैं (जैसे कि एपीआई) को हाइड / शो करना होगा।

— पियरे अरलाउड

Answer 5

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

मेरे लिए एक और महत्वपूर्ण तर्क पठनीयता है, मेरी राय में अच्छे कोड को गद्य की तरह पढ़ा जा सकता है, इसका वास्तव में अजीब गद्य है जैसे "main_window setVanish false" के बजाय "main_window hide", आप सामान्य रूप से लिखते हैं या बात करते हैं ?, इस अजीब का उपयोग क्यों करें? सॉफ्टवेयर प्रोग्राम में भाषा निर्माण जब पूरी तरह से संभव है एक अधिक प्राकृतिक भाषा का उपयोग करें ?.

Comments

क्या असेंबलर पर्याप्त नहीं है?

— अलेक्जेंडर

मैं उम्मीद करूंगा कि अनुक्रम it.setVisible(false); it.setVisible(true);को नियंत्रण के माता-पिता की दृश्यता को प्रभावित नहीं करना चाहिए, न ही यह नियंत्रण के Z आदेश या स्थान को प्रभावित करना चाहिए। इसके विपरीत hide(); show(); काफी हद तक एक नियंत्रण के माता-पिता को दिखाई देने के लिए मजबूर कर सकता है, इसे अन्य नियंत्रणों से ऊपर ले जा सकता है, और अपनी स्थिति को किसी ऐसे स्थान पर सीमित कर सकता है जिसे देखा जा सकता है। कुछ मामलों में, यह सुनिश्चित करने के साधन के लिए उपयोगी है कि कुछ वास्तव में दिखाई दे रहा है (जैसा कि पूर्वोक्त के साथ show(), लेकिन अन्य मामलों में दृश्यता ध्वज को बदलने के लिए कुछ और बदलने के बिना उपयोगी है ।

— Supercat

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

— अल्फ्रेडो कैसादो

Answer 6

मुझे विश्वास है कि विधि अधिक अभिव्यंजक है, अधिक पठनीय है, और परिणामस्वरूप, कोड को बनाए रखने योग्य होगा। निम्नलिखित दो मामलों पर विचार करें:

मामला एक:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  customerPanel.setVisible(customer.isCustomerEnabled());
}

केस 2:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  //always show customer panel
  customerPanel.setVisible(true);
}

पहले मामले में, यह स्पष्ट है कि फ़ंक्शन "सेटविजबल" क्या कर रहा है, लेकिन यदि आप इसे पढ़ना चाहते हैं, तो आप कहेंगे:

यदि ग्राहक सक्षम है या ग्राहक अक्षम है तो उसे छिपाकर सेट करने के लिए ग्राहक पैनल सेट करें।

जबकि कहने के लिए इसका अधिक वर्णनात्मक:

• ग्राहक की स्थिति की जाँच करें:
  • यदि ग्राहक सक्षम है तो ग्राहक का पैनल दिखाएं
  • अन्यथा, इसे छिपाएं

जो "केस 1" फ़ंक्शन को निम्नलिखित में बदल देगा:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  if(customer.isCustomerEnabled()){
    customerPanel.Show();
  }
  else{
    customerPanel.Hide();
  }
}

यह अधिक कोड का उत्पादन करता है, लेकिन अधिक पठनीय है।

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

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

Comments

मैं कहूंगा show customer panel iff the user/customer is enabled:। मैं इस बात से सहमत हूं कि बहुत अधिक जटिल स्थितियां हो सकती हैं जो आपके उदाहरण के रूप में पढ़ना आसान नहीं है, हालांकि, उन मामलों में मैं उन स्थितियों को अलग-अलग लाइनों में विभाजित कर दूंगा।

— कॉमफिक

Answer 7

मेरा मानना ​​है कि Hide()/ Show()विकल्प आकर्षक है क्योंकि यह समझना आसान है कि क्या चल रहा है SetVisible(true), जबकि एक ही कार्य करना बेहतर है क्योंकि यह बहुत सारी शर्तों से बचा जाता है।

अगर ऐसा है तो मैं इनपुट के रूप में एक गणना का उपयोग करने का सुझाव देता हूं SetVisible, ताकि आप SetVisible(Visibility.Visible)या तो प्राप्त करें या SetVisible(Visibility.Hidden)। आपके पास एक ही फ़ंक्शन है आप तुरंत पढ़ सकते हैं कि क्या कार्रवाई की जा रही है।

जावा के नामकरण सम्मेलनों का उपयोग करना, आप शायद setVisible(Visibility.VISIBLE)या होगा setVisible(Visibility.HIDDEN)।

Answer 8

मैं डेरेन के जवाब से सहमत हूं, लेकिन सी # प्रोग्रामर के दृष्टिकोण से एक दृष्टिकोण जोड़ना चाहता था।

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

मुझे नहीं पता कि यह आप जावा और सी ++ में क्या उम्मीद करते हैं, लेकिन यही मैं सी # में उम्मीद करूंगा, हालांकि सी # में इस गुण के लिए एक छोटा हाथ है। और यहाँ गुणों ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ) का उपयोग करने के बारे में कुछ अच्छा मार्गदर्शन दिया गया है ।

इस दृश्य को देखते हुए, फिर मैं जो इंटरफ़ेस चुनूंगा, वह पूरी तरह से इस बात पर निर्भर करेगा कि क्या कोई साइड इफेक्ट्स (उस फ़ील्ड मान को बदलने के अलावा) हैं:

यदि क्रिया करने के साइड इफेक्ट्स हैं, उदाहरण के लिए यह एक डायलॉग बॉक्स दिखा रहा है तो मैं "शो ()", और "हाईड ()" के साथ जाऊंगा।

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

C # (जावा के बारे में निश्चित नहीं) में पर्यवेक्षक पैटर्न को अपनाना बहुत आम बात है, जहाँ UI फ्रेमवर्क ऑब्जेक्ट्स में बदलावों के लिए सुनेगा और विजिबलिटी जैसे प्रॉपर्टी में बदलाव होने पर स्वतः ही UI री-रेंडर कर देगा। इसका मतलब है कि setIsVouble कॉल करके मान सेट करना ऐसा प्रतीत होता है जैसे इसके दुष्प्रभाव हैं, लेकिन मेरी परिभाषा में यह नहीं है। विजेट का अनुबंध "इस्विविवि" का प्रतिनिधित्व करते हुए फ़ील्ड मान सेट करके पूरा किया गया है।

एक और रास्ता रखो, यह मेरे लिए ठीक है कि फॉर्म दिखाए जाने से पहले एक फॉर्म पर एक लेबल की दृश्यता को टॉगल करें। Ie label.getIsV अदृश्य == सच, लेकिन फ़ॉर्म नहीं दिखाया गया है।

जब फ़ॉर्म प्रदर्शित नहीं हो रहा हो तो मुझे Hide () कॉल करना ठीक नहीं है।

Comments

साइड इफेक्ट्स के बिना किसी क्षेत्र तक पहुंचने का एक तरीका होने के रूप में आपका getXXX()और आपका वर्णन setXXX()जावा की तरह लगता है न कि सी #। यह वह तरीका है जो आपको जावा में करना चाहिए क्योंकि इसमें गुण नहीं हैं। अगर मुझे C # में ऐसा कोड दिखाई देता है, तो मुझे लगता है कि यह जावा डेवलपर द्वारा लिखा गया था, जिन्होंने C # में गुणों के बारे में अभी तक नहीं सीखा है।

— 15

के लिए +1 SetVisibility।

— अंकल

@ gilly3 - हां, बिल्कुल। और, CLR में "गुण" मौजूद नहीं है, C # पद्धति का अनुवाद IL में get_XXX और set_YYY है। मेरी बात यह है: प्रश्न के संदर्भ में, यदि आपने setXXX को देखा है, तो जावा में गेटएक्सएक्सएक्स आप इसे सी # गुण के समान शब्दार्थ के साथ काम करने की उम्मीद करेंगे। यह सच है, तो मैं यह बताता हूं कि C # में संपत्तियों के लिए समान दिशानिर्देश जावा में setXXX और getXXX के जोड़े पर लागू होते हैं। मैं पोस्ट में संदर्भित दिशानिर्देशों में सहमत होने के लिए होता हूं, और इसलिए मैं इंटरफ़ेस को परिभाषित करते समय जावा में इस परिदृश्य में उपयोग के लिए उन्हीं दिशानिर्देशों की वकालत कर रहा हूं।

— डैनियल जेम्स ब्रायर्स

यह स्पष्ट करने में मदद कर सकता है कि जब आप "साइड-इफेक्ट्स" का अर्थ करते हैं, तो आप का अर्थ है "एक 'अवलोकन योग्य चीज" होने के साथ जुड़े लोगों के अलावा। मैं जो नियम कहता हूं, वह यह है कि यदि किसी getXXकॉल की संगत setXXविधि है, तो setYYउसे प्रभावित नहीं करना चाहिए, लेकिन यह उस getZZकॉल को प्रभावित कर सकता है जिसमें कोई setZZविधि नहीं है ।

— सुपरकैट

Answer 9

मैं थोड़ा संशोधित इंटरफ़ेस सुझाता हूँ:

Show();
Hide();
ToggleVisible();
ToggleVisible(bool visible);

बेहतर नाम

ये विधि नाम डेवलपर को यह तय करने में मदद करते हैं कि किस विधि को उपयोग करने की आवश्यकता के आधार पर तय किया जाए। जबकि SetVisible(bool visible)एक डेवलपर भ्रमित कर सकते हैं क्योंकि यह रूप में एक ही अर्थ अर्थ बता देते हैं Show()और Hide(), Toggle()एक शर्त है कि कार्रवाई को निर्धारित करता है के अस्तित्व का तात्पर्य। इस प्रकार प्रत्येक विधि का उपयोग करने पर यह डेवलपर के लिए सहज हो जाता है।

कम कोड अतिरेक

आपके इंटरफ़ेस में कई तरीके होने का लाभ यह है कि यह कॉलिंग कोड को सरल बनाता है। आप सिर्फ उजागर कर सकते हैं Show()और Hide(), लेकिन:

• आपको शायद SetVisible()पर्दे के पीछे वास्तविक काम करने के लिए किसी तरह की निजी विधि की आवश्यकता होगी (या इसके लिए अनावश्यक कोड लिखें ) Show()और Hide()।
• कॉलिंग कोड में कई बेमानी हो सकते हैं यदि / अन्यथा ब्लॉक करने के लिए कि किस विधि का उपयोग करना है। यह मेरी राय में कोड को ब्लॉट करता है।
• यदि मैं उपभोक्ता होता, तो मैं केवल अपने स्वयं के रैपर फ़ंक्शन को लिखता हूँ जो कोड ब्लोट से बचने के लिए SetVisible()(या Toggle()) पहले से ही करता है (मुझे अनावश्यक कोड से नफरत है)। इस प्रकार एक ऐसी विधि की नकल करना जो संभवतः पहले से ही कार्यान्वयन में एक निजी विधि के रूप में मौजूद है।

Comments

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

— पैट्रिक एम

Answer 10

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

यदि किसी ऑब्जेक्ट को छुपाने और फिर से दिखाने के साइड-इफेक्ट्स हो सकते हैं जैसे Z ऑर्डर बदलना, तो इस तरह की क्रियाओं को अलग-अलग तरीकों से किया जाना चाहिए। ऐसे मामलों में, बाहरी तरीकों की उपयोगिता जो "दृश्यता" पैरामीटर को स्वीकार करते हैं, सीमित होंगे, और इसलिए उन्हें सुविधाजनक बनाने के लिए बहुत कम लाभ होगा। इसके अलावा, एक SetVisibleविधि (गलत तरीके से) यह सुझाव देगी कि वस्तुओं की दृश्यता में परिवर्तन बिना दुष्प्रभावों के पूरा किया जा सकता है।