एक ऐसी कक्षा है जो कई वर्गों को "ईश्वर वस्तु" का प्रबंधन करती है?

Question

the wikipedia entry about God Objects पढ़ना, यह कहता है कि एक वर्ग एक ईश्वर वस्तु है जब बहुत ज्यादा जानता है या बहुत अधिक करता है।

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

Answer 1

मुख्य कार्य/विधि विंडोज़, डेटाबेस, और अन्य वस्तुओं के अस्तित्व के बारे में जान सकती है। यह नियंत्रक को मॉडल पेश करने जैसे ओवर-आर्किंग कार्यों को निष्पादित कर सकता है।

लेकिन इसका मतलब यह नहीं है कि यह सभी छोटे विवरणों का प्रबंधन करता है। यह शायद डेटाबेस या विंडोज़ को कैसे कार्यान्वित किया जाता है, इस बारे में कुछ भी नहीं जानता है।

यदि ऐसा हुआ, तो यह भगवान वस्तु होने का आरोप लगाया जा सकता है।

Answer 2

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

यह विभिन्न वर्गों की अंतःस्थापितता या युग्मन नहीं है जो कि ईश्वर-वस्तुओं के साथ समस्या है, यह तथ्य है कि ईश्वर-वस्तु कई बार हासिल कर सकती है यदि उसके व्युत्पन्न बच्चों की सभी जिम्मेदारियां नहीं हैं, और काफी अप्रत्याशित हैं (डेवलपर के अलावा किसी अन्य व्यक्ति द्वारा) उनकी परिभाषित जिम्मेदारियों के अनुसार।

Answer 3

बस "एकाधिक" कक्षाओं के बारे में जानना एक भगवान को नहीं बनाता है; कई समस्याओं के समाधान के लिए कई वर्ग के बारे में जानना जो कई उप-समस्याओं में विभाजित होना चाहिए एक ईश्वर बनाते हैं।

मैं, लगता है ध्यान केंद्रित करने पर होना चाहिए कि क्या एक समस्या कई उप समस्याओं में विभाजित किया जाना चाहिए नहीं वर्गों की संख्या एक दिया वस्तु जानता है के बारे में पर (जैसा कि आप ने कहा, कभी कभी कई कक्षाओं के बारे में जानते हुए भी आवश्यक है) ।

देवताओं अति-प्रचारित हैं।

Answer 4

ए ईश्वर वस्तु एक ऐसी वस्तु है जिसमें संदर्भ, सीधे या अप्रत्यक्ष रूप से संदर्भ होते हैं, यदि किसी एप्लिकेशन के भीतर सभी ऑब्जेक्ट्स नहीं हैं। जैसा कि सवाल देखता है, एक आवेदन में भगवान वस्तु होने से बचना लगभग असंभव है। कुछ ऑब्जेक्ट को विभिन्न उपप्रणालीओं के संदर्भ रखना चाहिए: यूआई, डेटाबेस, संचार, व्यापार तर्क, आदि ध्यान दें कि भगवान वस्तु को एप्लिकेशन-परिभाषित नहीं होना चाहिए। कई ढांचे में "अनुप्रयोग संदर्भ", "एप्लिकेशन पर्यावरण", "सत्र", "सक्रियकर्ता", आदि जैसे नामों के साथ ईश्वरीय वस्तुओं का निर्माण किया गया है।

समस्या यह नहीं है कि कोई ईश्वर वस्तु मौजूद है, बल्कि यह कैसे है उपयोग किया गया। मैं एक चरम उदाहरण के साथ चित्रित करूंगा ...

मान लें कि मेरे आवेदन में मैं मानक प्रदर्शित करना चाहता हूं कि संख्याओं को प्रदर्शित करते समय सटीकता के कितने दशमलव स्थान दिखाना चाहते हैं। हालांकि, मैं परिशुद्धता विन्यास योग्य होना चाहता हूँ।

class NumberFormatter { 
    ... 
    String format(double value) { 
     int decimalPlaces = getConfiguredPrecision(); 
     return formatDouble(value, decimalPlaces); 
    } 

    int getConfiguredPrecision() { 
     return /* what ??? */; 
    } 
} 

सवाल, कैसे क्या लौटने के लिए getConfiguredPrecision आंकड़ा बाहर करता है: मैं एक वर्ग जिसका जिम्मेदारी है कि तार करने के लिए संख्या परिवर्तित करने के लिए बनाने के?एक तरीका NumberFormatter वैश्विक अनुप्रयोग संदर्भ का संदर्भ देना होगा जो इसे _appContext नामक सदस्य क्षेत्र में संग्रहीत करता है। फिर हम लिख सकते हैं:

return _appContext.getPreferenceManager().getNumericPreferences().getDecimalPlaces(); 

ऐसा करने से, हम सिर्फ NumberFormatter एक देवता वस्तु में रूप में अच्छी तरह बना दिया है! क्यूं कर? क्योंकि अब हम _appContext फ़ील्ड के माध्यम से आवेदन में वर्चुअल रूप से किसी ऑब्जेक्ट को (अप्रत्यक्ष रूप से) संदर्भित कर सकते हैं। क्या यह बुरा है? हाँ यही है।

मैं NumberFormatter के लिए एक यूनिट परीक्षण लिखने जा रहा हूं। चलिए पैरामीटर सेट अप करें ... इसे एप्लिकेशन संदर्भ की आवश्यकता है? डब्ल्यूटीएफ, जिसमें 57 विधियां हैं जिन्हें मुझे नकल करने की ज़रूरत है। ओह, इसे केवल प्रीफ मैनेजर की जरूरत है ... डब्ल्यूटीएफ, मुझे 14 तरीकों का मज़ाक उड़ाना है! संख्यात्मक prefs!? इसे पेंच करें, कक्षा काफी सरल है, मुझे इसकी जांच करने की आवश्यकता नहीं है ...

मान लें कि एप्लिकेशन संदर्भ में एक और तरीका था, getDatabaseManager()। पिछले हफ्ते हम एसक्यूएल का उपयोग कर रहे थे, इसलिए विधि ने SQL डेटाबेस ऑब्जेक्ट वापस कर दिया। लेकिन इस हफ्ते, हमने एक नोएसक्यूएल डेटाबेस में बदलने का फैसला किया है और विधि अब एक नया प्रकार लौटाती है। NumberFormatter परिवर्तन से प्रभावित है? हमम, मुझे याद नहीं है ... हाँ, यह हो सकता है, मुझे लगता है कि यह निर्माता में एक अनुप्रयोग संदर्भ लेता है ... मुझे स्रोत खोलने और एक नज़र डालने दो ... नहीं, हम भाग्य में हैं: यह केवल getPreferenceManager() तक पहुंचता है ... अब चलिए अन्य 93 वर्गों को जांचें जो पैरामीटर के रूप में अनुप्रयोग संदर्भ लेते हैं ...

यह वही परिदृश्य तब होता है जब प्राथमिकता प्रबंधक या संख्यात्मक प्राथमिकता ऑब्जेक्ट में कोई परिवर्तन किया जाता है। कहानी का नैतिक यह है कि किसी ऑब्जेक्ट को केवल उन चीजों के संदर्भ रखना चाहिए जिन्हें इसे अपना काम करने की आवश्यकता होती है, और केवल उन्हीं चीजों को। NumberFormatter के मामले में, इसे केवल एक पूर्णांक की आवश्यकता है - दशमलव स्थानों की संख्या। यह सीधे भगवान ईश्वर वस्तु द्वारा बनाया जा सकता है जो जादूगर संख्या (या pref प्रबंधक या बेहतर अभी भी, संख्यात्मक prefs) जानता है, बिना किसी ईश्वरीय वस्तु में फ़ॉर्मेटर को घुमाने के। इसके अलावा, संख्याओं को प्रारूपित करने के लिए आवश्यक किसी भी घटक को भगवान ऑब्जेक्ट के बजाय एक फॉर्मेटर दिया जा सकता है। चारों ओर जीतता है।

तो संक्षेप में, समस्या भगवान ईश्वर का अस्तित्व नहीं है बल्कि अन्य वस्तुओं को ईश्वर की तरह की स्थिति प्रदान करने का कार्य है।

संयोग से, इस समस्या को हल करने वाले डिजाइन सिद्धांत को Law of Demeter के रूप में जाना जाता है। या "एक रेस्तरां में भुगतान करते समय, सर्वर को अपना पैसा अपना वॉलेट नहीं दें।"