क्या होगा अगर ग्लोबल्स समझ में आते हैं?


10

मुझे एक मूल्य मिला है, जिसे कई वस्तुओं की आवश्यकता है। उदाहरण के लिए, वस्तुओं के रूप में विभिन्न निवेशों के साथ एक वित्तीय अनुप्रयोग और उनमें से अधिकांश को वर्तमान ब्याज दर की आवश्यकता होती है।

मैं एक वस्तु के रूप में अपने "वित्तीय वातावरण" को एक संपत्ति के रूप में ब्याज दर के साथ संलग्न करने की उम्मीद कर रहा था। लेकिन, जिन वस्तुओं को उस मूल्य की आवश्यकता होती है, वे इसे प्राप्त नहीं कर सकते।

तो मैं अपने डिजाइन को ओवर-कपलिंग के बिना कई वस्तुओं के बीच मूल्यों को कैसे साझा करूं? जाहिर है मैं इस गलत के बारे में सोच रहा हूं।


2
क्या आपकी गणना की अवधि के लिए ब्याज दर निर्धारित है या क्या आप एक सिमुलेशन की तरह कुछ कर रहे हैं जहां यह टाइमस्टेप्स के बीच भिन्न हो सकता है?
जेम्स

यह एक सिमुलेशन की तरह अधिक है - यह रन के दौरान बदल सकता है।
ग्रेग

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

3
आप एक सही ट्रैक हैं, एक Singletonओओ सिंथेटिक्स चीनी के साथ एक वैश्विक है और यह एक भयानक समाधान है जो कुछ सबसे खराब तरीकों से आपके कोड को कसकर जोड़े। इस लेख को तब तक पढ़ें जब तक आप इसे समझ न लें!

ब्याज दर एक टाइम सीरीज़ की तरह है जो कि एक फ़ंक्शन है जो DateTimeइनपुट के रूप में लेता है और आउटपुट के रूप में एक नंबर वापस करता है।
rwong

जवाबों:


14

मुझे एक मूल्य मिला है, जिसे कई वस्तुओं की आवश्यकता है।

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

तो मैं अपने डिजाइन को ओवर-कपलिंग के बिना कई वस्तुओं के बीच मूल्यों को कैसे साझा करूं?

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


17
असाधारण परिस्थितियों के साथ समस्या यह है कि वास्तविक विश्व सॉफ्टवेयर में वे असाधारण नहीं हैं।
मटनज़

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

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

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

@mattnz, समस्या यह है कि आपका हर एक उदाहरण उन मामलों में परिवर्तनशील है, जहाँ आप अपने प्रोग्राम को कई उपयोगकर्ता आधारों पर वितरित करते हैं, जो कंपनियों, राज्यों या देशों में हो सकते हैं। ये सभी समय के साथ परिवर्तनशील भी हो सकते हैं।
Dan Lyons

10

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

उदाहरण के लिए:

  • सर्विस लेयर (क्लास लाइब्रेरी) - एक सिंगलटन के माध्यम से FinancialEnvironment ऑब्जेक्ट का संकेत देता है
  • बिजनेस लॉजिक लेयर (क्लास लाइब्रेरी) - सर्विस लेयर से FinancialEnvironment ऑब्जेक्ट को स्वीकार करता है
  • डेटा एक्सेस लेयर (क्लास लाइब्रेरी) - सर्विस लेयर से FinancialEnvironment ऑब्जेक्ट को स्वीकार करता है (या आपके आर्किटेक्चर के आधार पर बिजनेस लॉजिक परत)। या हो सकता है कि सिंगलटन डेटा एक्सेस लेयर को इनवॉइस रेट (डेटाबेस / वेब सेवा / WCF सेवा) से ब्याज दर जैसी जानकारी प्राप्त करने के लिए आमंत्रित करता है।
  • एंटिटीज (या डीटीओ यदि आप इसे कॉल करना चाहते हैं) क्लास लाइब्रेरी - जहां FinancialEnvironment ऑब्जेक्ट रहता है। अन्य सभी कक्षा पुस्तकालयों में एंटिटीज़ क्लास लाइब्रेरी का संदर्भ है।

अन्य वर्ग केवल एंटिटी क्लास लाइब्रेरी के माध्यम से एक साथ बंधे होते हैं, वे एक तात्कालिक FinancialEnvironment ऑब्जेक्ट स्वीकार करते हैं। वे परवाह नहीं करते हैं कि यह कैसे बनाया गया था, केवल सेवा परत करता है, वे जो चाहते हैं वह जानकारी है। सिंगलटन कई FinancialEnvironment ऑब्जेक्ट्स को स्टोर करने के लिए पर्याप्त स्मार्ट हो सकता है, जो स्थानीय के लिए नियमों के आधार पर @Telastyn के रूप में बताया गया है।

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

अपडेट करें:

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

यदि मैं एक सट्टेबाजी का आदमी था, तो मैं शर्त लगा सकता हूं कि ब्याज दर एक डेटाबेस में कहीं संग्रहीत थी, या इसे एक वेब सेवा के माध्यम से पुनर्प्राप्त किया गया था। उस स्थिति में उस जानकारी को पुनः प्राप्त करने के लिए एक रिपॉजिटरी (डेटा एक्सेस लेयर) की सिफारिश की जाएगी। डेटाबेस की अनावश्यक यात्राओं से बचने के लिए (मुझे यकीन नहीं है कि ब्याज दरें कितनी बार बदलती हैं, या FinancialInformation वर्ग में अन्य जानकारी), कैशिंग का उपयोग किया जा सकता है। C # दुनिया में Microsoft की कैशिंग एप्लीकेशन ब्लॉक लाइब्रेरी बहुत अच्छी तरह से काम करती है।

केवल एक चीज जो ऊपर के उदाहरण से बदल जाएगी, सेवा परत में विभिन्न वर्ग होंगे जो कि फाइनेंशियल इंफॉर्मेशन की जरूरत है, जो ऑब्जेक्ट को सिंगलटन को इंस्टेंट करने के बजाय डेटा एक्सेस लेयर से पुनर्प्राप्त करेगा।


8
ओह। ग्लोबल को सिंगलटन बनाने से इसे कोई कम बदबूदार नहीं बनाता है। अगर कुछ भी आप अपने आप को प्रतिबंधित कर दिया है कि बहुत अधिक।
तेलस्टीन

3
@DavidCowden इससे कोई फर्क नहीं पड़ता कि वे लागू करने के लिए जटिल नहीं हैं; वे ग्लोबल्स की तुलना में आपके डिजाइन को खराब करते हैं। वे वैश्विक हैं और वे (अनावश्यक) प्रतिबंध लागू करते हैं कि आपके पास केवल एक है।
तेलस्तीन

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

4
SingletonOO सिंथैटिक चीनी के साथ एक वैश्विक और आलसी और कमजोर दिमाग के लिए एक बैसाखी है। कसकर अपने कोड को कुछ Singleton/globalकरने के लिए सबसे खराब तरीका है जो बाद में एक कैंसर होगा जब आपको पता चलता है कि यह एक बहुत बुरा विचार था और क्यों हर कोई कहता है कि वे हैं!

4
@ टेलस्टाइन: इसकी एक दुर्भाग्यपूर्ण वास्तविकता है कि सबसे सटीक डिजाइन एक बार जब वे सैद्धांतिक सॉफ्टवेयर डिजाइन की पूरी तरह से ऑर्डर की गई दुनिया को छोड़ देते हैं और वास्तविक दुनिया में शामिल हो जाते हैं, तो फ़ुबरैड हो जाते हैं।
मटनज़

4

विन्यास फाइल?

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


तो आपके पास हर बार ब्याज दर में बदलाव के लिए उपयोगकर्ता एक कॉन्फ़िगरेशन फ़ाइल अपडेट करेगा?
कालेब

2
क्यों नहीं? अक्सर बदलती रहने वाली चीजों के "परिवर्तनशील" पर निर्भर करता है, जिन्हें CENTRALIZED डेटास्टोर में रखा जाना चाहिए।
अंधेरी

1

मैं उस अनुभव से बोल रहा हूं जिसके पास लगभग एक महीने के रख-रखाव का एक अच्छा आकार (~ 50k LOC) प्रोजेक्ट है जिसे हमने अभी जारी किया है।

मैं आपको बता सकता हूं कि आप वास्तव में एक वैश्विक वस्तु नहीं चाहते हैं। प्रस्तुत है कि क्रौफ़्ट की तरह यह दुरुपयोग के लिए कई और अवसर प्रदान करता है जितना कि यह मदद करता है।

मेरा प्रारंभिक सुझाव यह है कि यदि आपके पास कई अलग-अलग वर्ग हैं जिन्हें वर्तमान ब्याज दर की आवश्यकता है, तो आप शायद उन्हें बस एक IInterestRateConsumerया कुछ को लागू करना चाहते हैं। उस इंटरफ़ेस के अंदर आपके पास एक SetCurrentInterestRate(double rate)(या जो कुछ भी समझ में आता है), या शायद सिर्फ एक संपत्ति होगी।

ब्याज दर पास करना वास्तव में युग्मन नहीं है - यदि आपकी कक्षा को ब्याज दर की आवश्यकता है, तो यह एपीआई का हिस्सा है। यह केवल युग्मन है यदि आपकी एक कक्षा वास्तव में इस बात की चिंता करने लगे कि अन्य वर्ग उस ब्याज दर का उपयोग कैसे करता है।


चारों ओर एक ब्याज दर पासिंग है युग्मन, यह सिर्फ नहीं है बुरा युग्मन।
वॉनगैंड्रोइड

1

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

बेशक, आपको सिंगलेट्स (यहां तक ​​कि प्रतिस्थापन योग्य सिंगलटन) बनाम हर जगह एक ही वस्तु को पारित करने के दर्द के साथ समस्याओं को तौलना होगा।

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


0

ब्याज दर डेटा को केंद्रीय कैश में क्यों नहीं रखा जाता है?

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

या पूरे हॉग पर जाएं और उन्हें एक डेटाबेस में संग्रहीत करें, जो आपको कई सर्वरों को स्केल करने की अनुमति देगा।


0

ऐसी स्थितियों में मैंने कभी-कभी कई परतों के साथ "संदर्भ" शब्द का सफलतापूर्वक परिचय (पुन: उपयोग) किया है।

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

दुकान या तो हो सकती है:

  • सख्ती से टाइप किया गया: आप सभी सर्व किए गए प्रकारों के लिए हेडर शामिल करते हैं और इसलिए आप टाइप किए गए एक्सेसर्स बना सकते हैं, जैसे InterestRate getCurrentInterestRate ();
  • या सामान्य: ऑब्जेक्ट getObject (enum obType); और केवल नए प्रकार (obtypeCurrentInterestRate) के साथ obType Enum का विस्तार करें।

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

एक और ध्यान दें: आपके पास विभिन्न उपयोगों के लिए एक ही ऑब्जेक्ट प्रकार के कई उदाहरण हो सकते हैं, जैसे कभी-कभी GUI के लिए अलग-अलग भाषा मूल्य और प्रिंटआउट, वैश्विक और सत्र स्तर लॉग आदि के लिए, इसलिए enum / accessor name को वास्तविक प्रकार को प्रतिबिंबित नहीं करना चाहिए , लेकिन अनुरोधित भूमिका (CurrentInterestRate) की भूमिका।

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

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

साइड नोट: कॉलर को अपने स्वयं के संदर्भों और अनुरोधित ऑब्जेक्ट के संदर्भ स्तर के बारे में बहुत अधिक नहीं जानना चाहिए। कारण: 1: इन मापदंडों के साथ खेलने से गलती करना आसान है (या "चतुर चाल"); 2: अनुरोध का संदर्भ स्तर बाद में बदल सकता है। मैं ज्यादातर संदर्भ जानकारी को थ्रेड से जोड़ता हूं, इसलिए ऑब्जेक्ट स्टोर में अनुरोध से अतिरिक्त मापदंडों के बिना जानकारी है।

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

आपके मामले के लिए यह एक प्रकार का ओवरकिल है (वैश्विक स्तर पर केवल एक ही वस्तु परोसी जाती है), लेकिन अभी काफी छोटे और सरल अतिरिक्त कोड के लिए, आपको आगे, शायद अधिक जटिल आवश्यकताओं के लिए एक तंत्र मिलता है।

एक और अच्छी खबर: यदि आप जावा में हैं, तो आपको बहुत ज्यादा सोचे बिना बसंत से यह सेवा मिल जाती है, मैं बस इसे विस्तार से बताना चाहता था।


0

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

  • अगर ब्याज दर अलग-अलग थी तो WOULD क्या होगा, इसकी गणना करने के लिए
  • कुछ घटक अमेरिकी ब्याज दर पर निर्भर करते हैं और कुछ घटक यूके की ब्याज दर पर निर्भर करते हैं

मैं ब्याज दर को "वित्तीय साधन" वर्ग का सदस्य बनाऊंगा, और स्वीकार करूंगा कि आपको इसे किसी भी सदस्य वर्ग (या तो प्रति-गणना, या उन्हें निर्माण पर एक संकेतक / हुक) में पारित करना होगा।


हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.