क्या यह एक बुरा फॉर्म है जो मुख्य/फॉर्म 1 के अलावा अन्य वर्गों को एक-दूसरे के साथ बातचीत करने की कोशिश करता है?

Question

मैं अपने कोड में कक्षाओं का उपयोग करने का सही तरीका सीखने की कोशिश कर रहा हूं, जब यह ग्राहकों के समूह की तरह कुछ स्पष्ट नहीं है, जानवरों से विरासत में कुत्तों आदि।

मैंने कोड के बड़े अनुभागों को तोड़ दिया है "विशेषताएं" जैसे Installer.cs, Downloader.cs, UiManager.cs। एकमात्र तरीका यह है कि मैं उन वर्गों को एक दूसरे के गुणों और विधियों के साथ बातचीत करने के लिए ढूंढ सकता हूं, उन्हें सभी स्थिर बनाना है, जिसे मुझे किसी अन्य प्रश्न में बताया गया है, यह गलत तरीका है।

1. कक्षाएं एक दूसरे से बात है कि मैं बस अभी तक समझ में नहीं आता बनाने के लिए एक तरीका होता है:

   तो मेरी समस्या 3 चीजों में से एक है।

2. वर्ग एक दूसरे से बात करने के लिए प्रयास करना चाहिए कभी नहीं, लेकिन एक बंद कार्रवाई करने और फिर कुछ लौट main/form1 है, जो मुख्य वर्ग तो एक बंद कार्रवाई के लिए किसी अन्य वर्ग में पारित करने के लिए उपयोग कर सकते हैं करने के लिए वापस।

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

सभी ट्यूटोरियल मैं पा सकते हैं और व्याख्यान मैं देखना ही में बताने के लिए लग रहे हैं कि कैसे कक्षाएं काम, लेकिन नहीं कब और कैसे उन्हें एक वास्तविक उत्पाद में उपयोग करने के लिए।

संपादित करें - एक अधिक सटीक उदाहरण:

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

मैं इसे स्ट्रिंग के बिना Form1 में उस स्ट्रिंग को रहने के लिए एक तरीका नहीं देख सकता (क्योंकि सभी फॉर्म इवेंट और फ़ंक्शंस इसे कक्षा में पास करने के लिए इसे देखने में सक्षम होने की आवश्यकता होगी)।

मैं स्ट्रिंग और पूरी कक्षा स्थिर बनाने के बिना स्ट्रिंग को किसी अन्य वर्ग में रखने का कोई तरीका नहीं देख सकता, इसलिए अन्य कक्षाएं इसमें देख सकती हैं।

शायद कुछ ऐसा है जो मुझे वास्तव में कक्षाओं को तुरंत चालू करने और वस्तुओं को एक-दूसरे के साथ बातचीत करने के बारे में याद आ रहा है।

Answer 1

मुझे लगता है कि आपके सभी अंतर्ज्ञान सही हैं।

1. नहीं, ऐसा नहीं है। स्टेटिक या उदाहरण।

2. यह एक डिज़ाइन विकल्प है (और वहां बहुत कुछ है)। मैं एक व्यावहारिक हूं, इसलिए मैं एक डिजाइन पैटर्न पर विचार करता हूं जो स्पैगुएथी कोड को खराब डिजाइन पैटर्न विकल्प उत्पन्न करता है। लेकिन एक परियोजना के लिए एक खराब डिजाइन पैटर्न एक और परियोजना के लिए एक अच्छा डिजाइन पैटर्न हो सकता है। हेड फर्स्ट डिज़ाइन पैटर्न बुक को पढ़ने का प्रयास करें।

3. हां, इंटरफेस और अमूर्त कक्षाएं हैं।

कुछ और विचार:

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

मेरे पास एक उपयोगिता प्रोजेक्ट है, और उपयोगिता प्रोजेक्ट के अंदर मेरे पास डेटा क्लास है। डेटा क्लास डेटाबेस तक पहुंच प्रदान करता है। यह एक स्थिर वर्ग है। क्यूं कर?

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

public abstract class Data 
{ 

    [...] 

    static Data() 
    { 
     #if DEBUG 
      _Connection = ConfigurationManager.AppSettings["debug"]; 
     #endif 

     #if RELEASE 
      _Connection = ConfigurationManager.AppSettings["release"]; 
     #endif 

     [...] 
    } 

    [...] 

} 

दिन के अंत में मैं स्थिर उपयोग करते हैं:

1. यह काफी सरल है (है कि मैं हर पहलू को नियंत्रित कर सकते);
2. यदि यह काफी छोटा है (मैं मान्यताओं के लिए विस्तार विधियों का उपयोग करता हूं, और वे स्थैतिक हैं) और;
3. यदि यह भारी उपयोग किया जाता है।

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

Answer 2

वर्ग eachother करने के लिए बात करते हैं, जब वे एक संदर्भ है, क्रम में एक बी के लिए एक संदेश पारित करने के लिए के लिए में, एक (या तो एक उदाहरण या स्थिर संदर्भ)

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

मुख्य वर्ग से जानकारी सार संक्षेप (या किसी भी वर्ग) के लिए आप इंटरफेस और अमूर्त कक्षाएं

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