वर्षों तक फॉर्म भरने और इंतज़ार करने के बाद, आपको अपना बैंकिंग लाइसेंस मिल ही गया। इसका मतलब है कि अब आप आधिकारिक रूप से अपना बैंक खोल सकते हैं, वाह!
आपकी पहली प्राथमिकता आईटी सिस्टम को काम करने लायक बनाना है। एक दिन की मेहनत के बाद, आप अब खाते खोल और बंद कर सकते हैं, और निकासी तथा जमा भी संभाल सकते हैं।
चूँकि आप टेस्ट लिखने की मेहनत नहीं करना चाहते थे, आप कुछ दोस्तों को सिस्टम परखने में मदद के लिए बुलाते हैं। लेकिन सिर्फ पाँच मिनट बाद, आपके एक दोस्त का दावा है कि उसका पैसा गायब हो गया है! हालाँकि आपको पूरा भरोसा है कि आपके कोड में कोई बग नहीं है, फिर भी आप जाँच करने के लिए लॉग देखने लगते हैं।
आह, हाँ, जैसा आपको संदेह था, गलती आपके दोस्त की ही है! उसने अपने टेस्ट क्रेडेंशियल किसी और दोस्त के साथ साझा किए, और दोनों ने मिलकर एक ही खाते से समानांतर में जमा और निकासी करने की चाल चली। ऐसा भला कौन करेगा?
जब आप यह तर्क करते हैं कि किसी के लिए अपने खाते को समानांतर में एक्सेस करना भौतिक रूप से असंभव है, तो आपका दोस्त आत्मसंतुष्ट होकर आपको बताता है कि बैंकिंग नियम आपको इसे सपोर्ट करने के लिए बाध्य करते हैं। इसलिए, समानांतर बैंकिंग सपोर्ट नहीं, तो लाइव होने का संकेत भी नहीं। आह भरते हुए, आप मन में लिख लेते हैं कि कल इस पर काम करना है। इससे आपकी लॉन्च तारीख कम से कम एक दिन और पीछे चली जाएगी, लेकिन जो भी हो...
आपको ऐसे बैंक खाते बनाने हैं जिन्हें खोला और बंद किया जा सके, और जिनमें पैसा जमा किया जा सके तथा निकाला जा सके।
बैंक खातों तक कई अलग-अलग तरीकों से पहुँचा जा सकता है (इंटरनेट, मोबाइल फोन, ऑटोमैटिक चार्ज), इसलिए आपके बैंक सॉफ्टवेयर को यह सुविधा देनी चाहिए कि एक ही समय में कई थ्रेड या प्रोसेस (यह शब्द आपकी प्रोग्रामिंग भाषा पर निर्भर करता है) खातों तक सुरक्षित रूप से पहुँच सकें। उदाहरण के लिए, एक साथ बहुत सारी जमा और निकासी हो सकती हैं; आपको यह सुनिश्चित करना है कि खाते का बैलेंस पढ़ने और नया बैलेंस सेट करने के बीच कोई रेस कंडीशन न हो।
खाता बंद करना भी संभव होना चाहिए। बंद खाते पर की जाने वाली हर कार्रवाई विफल होनी चाहिए।
यह अभ्यास कॉन्करेंसी से परिचित कराता है।
अंतिम टेस्ट पास करने के लिए आपको synchronized कीवर्ड या लॉक काम के लग सकते हैं।
कोड को एक साथ चलाने से पैदा होने वाली समस्याएँ अक्सर रुक-रुक कर दिखती हैं, क्योंकि वे इस पर निर्भर करती हैं कि कोड किस क्रम में चलता है। इसलिए अंतिम टेस्ट किसी बग को पकड़ने की संभावना बढ़ाने के लिए कई थ्रेड को कई बार चलाता है। इसका मतलब है कि अगर आपका कार्यान्वयन थ्रेड सेफ नहीं है, तो यह टेस्ट फेल होना चाहिए। लेकिन यह भी हो सकता है कि यह पास हो जाए, सिर्फ इसलिए कि एक साथ बदलाव करने की कोई कोशिश हुई ही नहीं। ऐसा लगातार कई बार होने की संभावना कम है, क्योंकि जब भी आप यह टेस्ट चलाते हैं, कोड के चलने का क्रम बदल जाना चाहिए। तो अगर आप अंतिम टेस्ट को दो-तीन बार चलाएँ और हर बार वह पास हो जाए, तो आप काफी हद तक निश्चित हो सकते हैं कि आपका कार्यान्वयन सही है।
Exercism पर साइन अप कीजिए और Java को 26 कॉन्सेप्ट158 अभ्यास तथा असली इंसानों से मिलने वाली मेंटरिंग के साथ सीखिए और उसमें महारत हासिल कीजिए, वह भी बिल्कुल मुफ्त।