मैं अपना कोड पुनर्गठित कर रहा हूं और इसलिए नए नामस्थान बना रहा हूं। मैं मॉड्यूल के लिए "स्थैतिक" कक्षाएं (प्रत्येक विधि में @staticmethod के साथ कक्षाएं) बदल रहा हूं। यह जाने का रास्ता है, है ना?मॉड्यूल के बीच संसाधनों का अच्छा अभ्यास साझा करना?
समस्या यह है कि मुझे इन मॉड्यूल के बीच संसाधनों को साझा करने के तरीके पर संदेह है।
मान लें कि मेरे पास एक मॉड्यूल था जिसमें से मैं डेटाबेस से सभी कनेक्शन कर रहा था, और निश्चित रूप से सभी वर्ग/विधियां डीबी कर्सर (मैं SQLite का उपयोग कर रहा हूं) को संग्रहीत चर साझा कर रहा था। अब, विभिन्न मॉड्यूल में, उन्हें कर्सर को भी साझा करना होगा।
तो, मेरे विचारों:
प्रत्येक मॉड्यूल में वैश्विक चर घोषित करें। लेकिन ग्लोबल्स बुरा हैं, बच्चों को खाएं और अपनी नौकरी चुराएं। तो मुझे नहीं पता कि यह जाने का रास्ता है या नहीं।
'''Sub Module 1''' global database_cursor
आयात मूल database_cursor साथ "पिता" database_module और प्रयोग कुछ इस तरह:
'''Sub Module 1''' db_cursor = database_module.database_cursor
यह दूसरा इस मामले में ठीक लग रहा है, लेकिन मैं कई मामलों का नेतृत्व करेंगे में लगता है आयात करने के लिए आयात, जो मुझे लगता है कि यह बचने के लिए कुछ है।
मुझे लगता है कि आप [overengineering] हो सकते हैं (http://en.wikipedia.org/wiki/Overengineering)। यदि कार्यों को काम करने के लिए कर्सर की आवश्यकता होती है तो बस कार्यों में पैरामीटर 'कर्सर' जोड़ें और आप कर चुके हैं। कोड जो सभी फ़ंक्शन को कॉल करता है, एक स्थानीय वैरिएबल बना देगा जिसमें कर्सर होता है और इसे सभी कार्यों में पास करता है। साथ ही, मैं कहूंगा कि डेटाबेस प्रबंधन के लिए एक एकल मॉड्यूल पर्याप्त है। यदि आपको लगता है कि आपको अधिक संगठन की आवश्यकता है तो आप 'SQLAlchemy' जैसी चीज़ों का बेहतर उपयोग कर रहे हैं। – Bakuriu
मुझे नहीं लगता कि यह इंजीनियरिंग खत्म हो गया है। अनावश्यक पुनर्नवीनीकरण से बचने के लिए डेटाबेस कनेक्शन जैसी चीज़ों को साझा करना पूरी तरह से वैध है। हालांकि मुझे लगता है कि इसके लिए कनेक्शन पूलिंग देखना बुद्धिमानी है। अन्यथा आपको पिछली कॉल से अभी भी कनेक्शन में कनेक्शन के साथ समस्याएं मिलती हैं। – RickyA