SOLID Design Principles | part 2

हां जी करें स्टार्ट। सो वेलकम बैक कोडर आर्मी हमारे इस एलएलडी की सीरीज़ में। सो लास्ट लेक्चर में हम सॉलिड डिज़ाइन प्रिंसिपल्स को डिस्कस कर रहे थे। जिसमें से हमने सिंगल रिस्पांसिबिलिटी को, ओपन क्लोज़ को और लिस्क को ऑफ सब्स्टट्यूशन को ऑलरेडी डिस्कस कर लिया था। अब हमारे दो अ प्रिंसिपल्स और रह गए हैं। तो फटाफट उसे डिस्कस करते हैं और इसे खत्म करते हैं। तो चलो आ जाओ स्क्रीन पे। तो हमने लास्ट वीडियो में जैसे आपको याद होगा सिंगल रिस्पांसिबिलिटी, ओपन क्लोज और लिस्ट ऑफ सब्स्टट्यूशन को ऑलरेडी डिस्कस कर लिया था। हमारे पास बस I और D जो कि इंटरफेस सेग्रगेशन और डिपेंडेंसी इन्वर्जन है वो रह गए थे। अब इन दोनों पे शिफ्ट होने से पहले इन दोनों पे शिफ्ट होने से पहले मैं लिस्क ऑफ सब्स्टट्यूशन के बारे में थोड़ी सी और बात करना चाहता हूं। क्यों? क्योंकि याद है लास्ट वीडियो में मैंने आपको बोला था ये प्रिंसिपल दिखने में तो बहुत सिंपल है। बट ये सबसे ज्यादा ब्रेक होने वाला प्रिंसिपल है। इसको बहुत ब्रेक करते हैं लोग। क्योंकि कई बार लोग इसे आइडेंटिफाई नहीं कर पाते कि यहां पे लिस्क ऑफ सब्स्टट्यूशन ब्रेक भी हो रहा है। थोड़ा सा ट्रिकी हो जाता है ये। तो कुछ रूल्स हैं, कुछ प्रिंसिपल्स हैं जिसको आप कुछ गाइडलाइंस कह लो जिनको अगर आप फॉलो करो तो कभी भी आप रिस्क ऑफ सब्स्टट्यूशन ब्रेक नहीं करोगे। एक अच्छा वेल मेंटेंड कोड लिख पाओगे। लाइफ प्रोजेक्ट पे जब आप काम करोगे बहुत जरूरी होगा और खास करके इंटरव्यूज में बहुत जरूरी होगा। तो एक बार मेरे साथ बने रहो। उस गाइडलाइंस को देख लेते हैं फटाफट और फिर हम मूव करेंगे नेक्स्ट प्रिंसिपल की तरफ। ठीक है? तो देखो स्टार्ट करते हैं लिस्क ऑफ सब्सीट्यूशन पे दोबारा से। चलो देखो अगर आपको याद होगा तो लिस ऑफ सब्स्टट्यूशन प्रिंसिपल में हमने क्या डिस्कस किया था? हमने ये डिस्कस किया था कि लेट्स से हमारी एक पेरेंट क्लास है लेट्स से A और उसकी एक चाइल्ड क्लास है लेट्स से B और एक क्लाइंट है। ठीक है? लेट्स से यह क्लाइंट है। तो मैंने लिस ऑफ सब्स्टिट्यूशन में आपको बताया था कि जब भी क्लाइंट ए एक्सपेक्ट करे और मैं अगर उसको B दे पाऊं बिना क्लाइंट को कोई फर्क करे बिना क्लाइंट का कोड फटे या कुछ भी रेस्ट्रिकशंस ना आए तो मैं कहूंगा कि वो हायरार्की एक लिस्ट ऑफ सब्स्टिट्यूशन प्रिंसिपल को फॉलो करती है। यही था कि चाइल्ड क्लास कैन इज़ली रिप्लेस द पेरेंट क्लास। राइट? अब इसको फॉलो करने के लिए ना थोड़ी सी गाइडलाइन समझो। देखो ऐसे ही थोड़ी ना कि ये जो बी चाइल्ड क्लास है ये ए को कभी भी रिप्लेस कर देगी। देखो इन्हहेरिटेंस में हमने समझा था कि A के पास जो भी मेथड्स होते हैं लेट्स से A के पास कुछ मेथड्स हैं M1 M2 सबसे पहले B को वो ओवराइड करने पड़ते हैं। तो B भी वो M1 M2 ओवराइड करेगा सबसे पहले तो। राइट? बस उसको ओवराइड करने से वो इन्हहेरिटेंस को तो फॉलो कर लेता है। पर जरूरी नहीं है वो लिस्क ऑफ सब्सीट्यूशन को फॉलो करे। यानी कि ज़रूरी नहीं है हर वह चाइल्ड क्लास जो पेरेंट क्लास की एक सब क्लास है वह अपने पेरेंट क्लास को इज़ली रिप्लेस कर दे। कैसे? देखो समझो इसको। जो भी चाइल्ड क्लास है ना वो सिर्फ पेरेंट क्लास के मेथड्स को ही अ अगर सिर्फ इनहेरिट कर रही है तो हो सकता है वो गलत इनहेरिट करे। हो सकता है वो जैसे हमने अपने अकाउंट के सेक्शन में देखा था विथड्रॉ की तरफ से उसने क्या किया? विथड्रॉ बंद कर दिया फिक्स्ड डिपॉजिट अकाउंट ने। राइट? हो सकता है वो उस तरह इन्हहेरिट करे जो कि गलत हो जाएगा। राइट? तो B को सिर्फ A को इन्हहेरिट ही नहीं करना है। B को सिर्फ ए को इन्हहेरिट ही नहीं करना है। बस B को A की तरह रिस्पांस करना है। A की तरह बिहेव करना है। तो अ चाइल्ड क्लास शुड बिहेव लाइक अ पेरेंट क्लास। बेसिकली मतलब कहने का ये है कि जो क्लाइंट है ना उसे कोई फर्क ही नहीं पता लगना चाहिए पेरेंट क्लास और चाइल्ड क्लास के अंदर। राइट? तो इसी सब के लिए रिगार्डिंग वो गाइडलाइंस हैं। तो फटाफट देखते हैं वो कौन सी गाइडलाइंस है। ठीक है? तो जो गाइडलाइंस है ना वो तीन पार्ट्स में डिवाइडेड है। ठीक है? बहुत सिंपल-सिंपल पार्ट है। तो सबसे पहले तो वो गाइडलाइंस तीन पार्ट्स में डिवाइडेड हैं। कौन-कौन सी गाइडलाइन है? देखो, सबसे पहले हमारा आता है सिग्नेचर रूल। ठीक है? क्या होता है सिग्नेचर रूल? किसी भी मेथड के सिग्नेचर को हम क्या कहते हैं? उस मेथड का नाम, उस मेथड के आर्गुमेंट्स जो वो लेता है और उस मेथड का एक रिटर्न टाइप ये सब मिला के एक मेथड का सिग्नेचर कहलाता है। राइट? अभी देखेंगे रूल क्या कहता है। इसके अलावा हमारे पास होता है प्रॉपर्टी रूल। और लास्ट होता है हमारे पास मेथड रूल। देखते हैं एक-एक करके क्या कहते हैं ये तीनों। ठीक है? सबसे पहले फटाफट से सिग्नेचर रूल को देखते हैं। ठीक है? देखो सबसे पहले ना इसकी थ्योरी समझेंगे और फिर देखेंगे कोड में, C++ में, जावा में इसे कैसे इंप्लीमेंट कर सकते हैं। उससे पहले एक चीज समझ लो। जब भी मैं वर्ड यूज़ करूंगा ब्रॉड, तो इसका मतलब क्या होगा? और जब भी मैं ये वर्ड यूज़ करूंगा नैरो, तो इसका मतलब क्या होगा? देखो जब भी मैं बोलूंगा ना कि एक क्लास दूसरे क्लास की ब्रॉडर क्लास है। तो ब्रॉडर मतलब उसकी पेरेंट क्लास या पेरेंट में कोई भी एनसेेस्टर होना। राइट? फॉर एग्जांपल हमारे पास लेट्स से एक एनिमल क्लास है और एनिमल की एक सब क्लास हो सकती है। लेट्स से डॉग। तो जो एनिमल है वो डॉग की एक ब्रॉडर क्लास है। राइट? सेम वे में नैरो मतलब उसकी चाइल्ड क्लास या उसके डिसेंडेंट्स में होना। तो सेम वे में जो डॉग है ना वो एनिमल क्लास की नैरो क्लास है। बस इतना सा याद रखना। आपको बहुत हेल्प होगी अभी जब हम डिस्कस करेंगे। चलो आ जाते हैं वापस से सिग्नेचर रूल पे। तो समझते हैं सिग्नेचर रूल। देखो सपोज़ करो हमारे पास एक पेरेंट क्लास है। ठीक है? मैं इसको सिंपली क्लास पेरेंट करके लिख देता हूं। ओके? और हमारी एक चाइल्ड क्लास है। ठीक है? तो सेम वे में मैं एक चाइल्ड क्लास बना लेता हूं। क्लास चाइल्ड। और ये इन्हहेरिट कर रही है इस पेरेंट क्लास को। तो हम क्या लिखते हैं? पब्लिक पेरेंट। राइट? हम ऐसे ही लिखते हैं। है ना? अब सपोज़ करो ये जो पेरेंट क्लास है ना इसके पास एक मेथड है। लेट्स से मेथड का नाम है सॉल्व। ठीक है? अ लेट्स से वो वॉइड मेथड है। कुछ रिटर्न नहीं करता और वो एक आर्गुमेंट लेता है स्ट्रिंग टाइप का। स्ट्रिंग एस और इसके बाद वो कुछ-कुछ करता है। राइट? हमें उससे मतलब नहीं वो क्या करता है। पर बस कहने का मतलब ये था कि हमारे पास एक मेथड है सॉल्व जो एक स्ट्रिंग आर्गुमेंट लेता है। ठीक है? जब आप इस मेथड को ओवराइड करोगे अपनी चाइल्ड क्लास में तो आप क्या करोगे? सेम एक मेथड लिखोगे सॉल्व। राइट? अब मेथड आर्गुमेंट सॉरी सिग्नेचर रूल ये कहता है कि जहां जो आपने यहां पे सि आर्गुमेंट लिया था स्ट्रिंग टाइप का सेम आर्गुमेंट आपको यहां लेना पड़ेगा या तो उसका ब्रॉडर आर्गुमेंट लेना पड़ेगा। यानी कि यहां आर्गुमेंट में आपने जो भी ऑब्जेक्ट दिया जैसे यहां पे हमने एक स्ट्रिंग टाइप का ऑब्जेक्ट दिया। तो या तो आप सेम ऑब्जेक्ट यहां पे पास करो स्ट्रिंग टाइप का या फिर उससे एक ब्रॉडर ऑब्जेक्ट जा कि जो कि से स्ट्रिंग की एक पेरेंट क्लास हो सकती है वो पास करो। तो या फिर हमें यहां पे लिखना पड़ेगा सेम स्ट्रिंग एस टाइप का। अब ये तो बहुत सिंपल रूल है। ये तो बेसिकली C++ खुद ही इंपोज़ करती है। मतलब मेथड सिग्नेचर C++ में हमेशा सेम होना चाहिए। ओवराइड फंक्शन में अगर आपको याद हो। तो इसका मतलब ये होता है कि जब भी आप यहां पे ओवराइड करते हो किसी भी मेथड को जैसे यहां पे आपने सॉल्व को ओवराइड किया है तो जैसे सॉल्व स्ट्रिंग लेती है तो ये वाला सॉल्व भी स्ट्रिंग ही लेगा। आप यहां पे कुछ और डाल ही नहीं सकते। तो C++ आपको इंपोज़ करता है। तो ये एक थ्योरिटिकल रूल है। ये लैंग्वेज इंडिपेंडेंट रूल है। ये जावा भी इंपोज़ करता है वैसे तो। पर ये लैंग्वेज इंडिपेंडेंट रूल है। अगर आपको समझना हो तो आप इसे कैसे समझोगे कि क्यों हम कह रहे हैं जो चाइल्ड क्लास का आर्गुमेंट है वो पेरेंट क्लास के या तो एग्जैक्ट इक्वल होना चाहिए या उसे ब्रॉडर होना चाहिए। देखो समझो इसको ऐसे कि सपोज़ करो हमारे पास एक क्लाइंट है। ठीक है? और हम कर क्या रहे होते थे? हम इस क्लाइंट को जो पेरेंट क्लास का ऑब्जेक्ट एक्सपेक्ट कर रहा था हम उसको चाइल्ड क्लास का ऑब्जेक्ट दे देते थे और क्लाइंट को पता नहीं चलता था। क्योंकि क्लाइंट वही मेथड चाइल्ड पे भी कॉल कर सकता था और कुछ कोड नहीं फटता था। राइट? अब लेट्स सपोज़ इस केस में जहां पे हमने क्या किया? गलती से चाइल्ड में स्ट्रिंग की जगह यहां पे हमने लगा दिया लेट्स से इंटिजर इंट। ठीक है? तो अब ये जो सॉल्व का फंक्शन है इंट ले रहा है। पेरेंट का फंक्शन है स्ट्रिंग ले रहा है। लेकिन क्लाइंट को तो सिर्फ इस बात का पता है कि मैं सॉल्व फंक्शन कॉल कर सकता हूं। है ना? इस पेरेंट के ऑब्जेक्ट P पे लेट्स से क्लाइंट के पास एक ऑब्जेक्ट है P इस पेरेंट का। तो वो इस P के फंक्शन P के रेफरेंस पे सॉल्व को कॉल कर सकता है। अब जब भी वो सॉल्व को कॉल करेगा उसको तो यही पता है ना बाय द कॉन्ट्रैक्ट। कॉन्ट्रैक्ट क्या था? इंटरफ़ेस जो हमारा इंटरफ़ेस था जो बेसिकली एक एब्स्ट्रैक्ट क्लास हो सकती है। जैसे कि ये पेरेंट है यहां पे। उसको तो यही पता है कि ये जो मैं मेरे को जो पेरेंट क्लास का फंक्शन कॉल करना है उसमें एक स्ट्रिंग टाइप का आर्गुमेंट देकर कॉल करना है। अगर मैंने उसको इंटीजर दे के अ कॉल कर दिया तो वो तो गलत हो जाएगा। क्यों? क्योंकि देखो जो इंटीजर है ना वो स्ट्रिंग का कोई अ पेरेंट क्लास नहीं है। राइट? ना कि स्ट्रिंग की कोई बराबर की क्लास है। स्ट्रिंग इंटीजर एक बिल्कुल ही अलग क्लास है स्ट्रिंग से। राइट? वैसे तो C++ में इंट इज़ नॉट अ क्लास। ठीक है? आप वो एक प्रिमिटिव डेटा टाइप है। पर आप मान लो। ठीक है? अगर हम नॉन प्रिमिटिव बनाने के लिए एक खुद का इंटीजर क्लास लिख सकते थे। जावा में तो इसकी अपनी क्लास होती है। राइट? पर आप मान लो तो ये एक इंटीजर एक अलग क्लास है और स्ट्रिंग एक अलग क्लास है। ठीक है? तो जब हमने यहां पे अगर स्ट्रिंग दे के कॉल कर दिया तो यहां तो कोड फट जाना चाहिए क्योंकि ये तो इंट एक्सपेक्ट कर रहा है और ये तो पेरेंट क्लास भी नहीं है। राइट? तो इसलिए हम कहते हैं कि सिग्नेचर रूल में जो कि सेम आर्गुमेंट हमने पेरेंट में पास की वही सेम होनी चाहिए चाइल्ड के पास भी। और ये आप कर ही नहीं सकते कि वो सेम ना हो क्योंकि C++ आपको इंपोज करता है। अच्छा यहां पे इंट और स्ट्रिंग का एग्जांपल दे के शायद थोड़ा सा समझ कम आया होगा। पर अभी दूसरा जो हम प्रिंसिपल देखेंगे ना उसमें एक बेटर एग्जांपल देखेंगे तो उससे आपको ज्यादा चीज समझ आ पाएगी। पर अभी आप समझ गए सिग्नेचर रूल ये तो वैसे भी C++ खुद ही इंपोज करता है। तो इसको आप वैसे भी कभी ब्रेक नहीं कर सकते। तो आओ इसका फटाफट से सेम तरीके से कोड देख लेते हैं। आ जाओ स्क्रीन पे। तो आप ये देख सकते हो हमने सेम कोड है। यहां पे हमने देखो पेरेंट क्लास लिया और एक चाइल्ड क्लास लिया। दोनों के पास प्रिंट का फंक्शन है। तो ये स्ट्रिंग एक्सपेक्ट करता है। ये भी स्ट्रिंग ही एक्सपेक्ट करेगा जब इसे ओवराइड कर रहा होगा। देखो तो अगर हमने गलती से भी यहां पे इंट लिखा तो आप देखो हमारे पास कंपाइलेशन एरर आ गया। क्या कह रहा है ये? मेंबर फंक्शन डिक्लेयर्ड विद ओवराइड डज़ नॉट ओवराइड अ बेस क्लास मेंबर। तो इसके हिसाब से अब इसको ये ओवराइड कर ही नहीं रहा क्योंकि सिग्नेचर डिफरेंट हो गया। इस सिग्नेचर में स्ट्रिंग है और इस सिग्नेचर में इंटीजर है। तो यहां पे हमें स्ट्रिंग ही लिखना पड़ेगा। तो ये रूल है। राइट? तो ये तो सिंपल है। अब देखो मैंने यहां पे क्या किया? एक क्लाइंट बना लिया जो एक पेरेंट क्लास का ऑब्जेक्ट P एक्सपेक्ट कर रहा है। हमने उसको कंस्ट्रक्टर में रेफर करवा लिया और उसके बाद हमने क्या किया? एक फंक्शन बना लिया प्रिंट मैसेज जो इस पेरेंट क्लास ऑब्जेक्ट P के फंक्शन प्रिंट को कॉल कर रहा है हेलो पास करके। ठीक है? अब चाहे आप यहां पे पेरेंट पास कर दो या चाइल्ड पास कर दो। कोई फर्क नहीं पड़ता। या तो चाइल्ड का मैसेज प्रिंट हो जाएगा या पेरेंट का क्योंकि हमने पहला प्रिंसिपल को फॉलो किया है जो कि है सिग्नेचर रूल। राइट? चलो अब सेकंड प्रिंसिपल देखते हैं। आ जाओ वापस स्क्रीन पे। चलो आई होप आपको यह वाला रूल समझ आया होगा। यह सिग्नेचर रूल के अंदर इसको हम बोलते हैं मेथड आर्गुमेंट रूल। क्योंकि ये क्या कर रहा है? सिग्नेचर के मेथड आर्गुमेंट से डील कर रहा है। ठीक है? एक किसी भी मेथड के सिग्नेचर के मेथड आर्गुमेंट से डील कर रहा है। तो इसको मेथड आर्गुमेंट रूल बोलते हैं। सिग्नेचर रूल में और भी दो हैं। ठीक है? इसके अलावा यहां पे होता है एक रिटर्न टाइप रूल। ठीक है? एक बार ये भी देख लेते हैं। तीनों बहुत आसान है। मेथड आर्गुमेंट, रिटन टाइप और इसके अलावा एक एक्सेप्शन है। पहले ये देख लेते हैं फटाफट। ये क्या कहता है? देखो इस एग्जांपल को ढंग से समझते हैं। पहले एक हायरार्की समझ लो। सपोज़ हमारे पास एक हायरार्की ऐसे है कि हमारे पास लेट्स से एक एनिमल क्लास है। और लेट्स से हमारे पास एक एनिमल है डॉग। ये उसकी चाइल्ड क्लास है। ठीक है? ये हायरार्की है। तो डॉग इज़ अ रिलेशनशिप है। राइट? डॉग इज़ अ एनिमल। अब रिटर्न टाइप रूल ये कहता है इस हायरार्की को ध्यान से सो समझ के रखना ये अलग है। ठीक है? अब यहां पे हम क्या करते हैं? एक एक और हायरार्की बनाते हैं। लेट्स सपोज़ यहां पे हमारे पास एक पेरेंट क्लास है और उसकी हमारे पास एक चाइल्ड क्लास है। ठीक है? हम इसका चलो अ यूएमएल नहीं सीधा कोड लिखते हैं तो ज्यादा बेटर समझ आएगा। तो हमारे पास क्या है? हमारे पास एक क्लास है पेरेंट और वैसे ही हमारे पास एक क्लास है चाइल्ड जो कि सेम क्या करती है? इन्हहेरिट करती है पेरेंट को। ठीक है? अब वही चीज सेम करते हैं। सपोज़ करो हमारे पास पेरेंट वाली क्लास में एक मेथड है। उस मेथड का नाम है लेट्स से सम रेंडम मेथड। वो कोई आर्गुमेंट नहीं लेती और अंदर कुछ-कुछ करती है। पर कोई आर्गुमेंट तो नहीं लेती पर लेट्स से वो जो रैंडम क्लास है ना वो एक रिटर्न टाइप तो वो बेसिकली जो रिटर्न करेगी राइट वो तो लेती है वो वॉइड नहीं है इस बार इस बार वो क्या करती है? एक एनिमल टाइप का ऑब्जेक्ट रिटर्न करती है। तो मैं यहां पे एनिमल लिख देता हूं। ठीक है? यानी कि ये जो मेथड है रैंडम ये एक एनिमल टाइप का ऑब्जेक्ट रिटर्न करेगा। ठीक है? तो रिटर्न टाइप रूल ये कहता है जब मैं इस मेथड को ओवराइड करूंगा यानी कि जब मैं इस चाइल्ड क्लास में इसको ओवराइड करूंगा इस रैंडम फंक्शन को तो उस ओवराइड के अंदर या तो मैं सेम रिटर्न टाइप रख सकता हूं व्हिच इज़ एनिमल ओनली। ठीक है? या फिर उसका सब टाइप रख सकता हूं या फिर उसका नैरो टाइप रख सकता हूं। जैसे कि डॉग रख सकता हूं। ठीक है? पर मैं कभी भी एनिमल का ब्रॉडर क्लास नहीं रख सकता या किसी एनिमल का एनसेेस्टर नहीं रख सकता। क्यों? अब इसको आप थोड़ा सा ध्यान से सोचो कि लेट्स सपोज हमारे पास एक क्लाइंट है। ठीक है? क्लाइंट क्या करता है? वो पेरेंट क्लास से एक्सपेक्ट कर रहा है कि वो मुझे एक एनिमल क्लास का ऑब्जेक्ट ला करके देगा। सपोज़ तो वही है। हमारे पास क्लाइंट के पास एक पेरेंट क्लास का ऑब्जेक्ट P है। ठीक है? तो वो उस P पे क्या करता है? P का रैंडम फंक्शन कॉल करता है और उसको एक एनिमल क्लास के ऑब्जेक्ट में पुट कर देता है। एनिमल A = दिस। ठीक है? तो अब इसमें क्या किया? इसने एनिमल क्लास के रेफरेंस में पी का रैंडम कॉल किया तो पी के रैंडम ने उसको क्या किया? एनिमल क्लास का एक ऑब्जेक्ट ला करके दे दिया। तो यहां पे कोई ऐसा करता होगा न्यू एनिमल ये ऐसे कुछ रिटर्न करता होगा। ठीक है? यहां पे वो रिटर्न करता होगा। लेट्स सपोज ठीक है? हमने लिखा नहीं है पर आप मान लो सेम यहां पे ये रिटर्न करता होगा न्यू एनिमल। सेम बिल्कुल। राइट? तो कहने का मतलब बस ये था। तो क्लाइंट क्या कर रहा है? ये P का जो रैंडम फंक्शन कॉल करता है उसको एनुअल क्लास के रेफरेंस को अटैच करके दे देता है। राइट? अब मैंने यहां पे क्या बोला रिटर्न टाइप रूल में कि जो चाइल्ड क्लास है या तो वो सेम रिटर्न टाइप रखें या इसे नैरो रिटर्न टाइप रखें। तो ऐसा क्यों? देखो अगर वो सेम रिटर्न टाइप रखती है और मैंने क्लाइंट को चाइल्ड दे दिया रादर दैन पेरेंट तो यहां पे उस ये जो पी है पी रेफरेंस है उसके पास चाइल्ड का रे ऑब्जेक्ट बन गया। तो यहां पे पी के पास चाइल्ड का रेफरेंस मिल गया। राइट? इतना समझ आ गया? अब जब ये P डॉट रेंडम कॉल करेगा तो वो चाइल्ड का ये वाला फंक्शन कॉल करेगा। है ना? अब जब चाइल्ड का ये वाला फंक्शन कॉल करेगा ये भी एनिमल रिटर्न करेगा और ये इस एनिमल को पॉइंट हो जाएगा। कोई दिक्कत नहीं है। पर मैंने क्या कहा? नैरो भी हो सकता है। लेट्स से ये एनिमल रिटर्न नहीं करता। हम एक काम करते हैं। इसमें एनिमल की जगह डॉग रिटर्न करवा लेते हैं। ठीक है? तो देखते हैं क्या होता है। यहां पे मान लो ये डॉग क्लास का ऑब्जेक्ट रिटर्न करता है। अब क्या होगा? अब जब ये P डॉट रैंडम एक डॉग टाइप का ऑब्जेक्ट रिटर्न करेगा तो भी ये जो एनिमल है रेफरेंस A उसको पॉइंट कर लेगा। क्योंकि एक पेरेंट क्लास का ऑब्जेक्ट एक चाइल्ड क्लास के एक पेरेंट क्लास का रेफरेंस चाइल्ड क्लास के ऑब्जेक्ट को पॉइंट कर सकता है। राइट? तो तब भी कोई दिक्कत नहीं होगी। दिक्कत सिर्फ तब होगी जब यहां पे लेट्स से ये डॉग की जगह लेट्स से यहां पे एक डॉग की जगह ये एनिमल क्लास के भी किसी पेरेंट को रिटर्न करता। अब एनिमल का मान लो कोई पेरेंट है ऑर्ग ऑर्गेनिज्म। ठीक है? तो लेट्स से यहां पे कोई ऑर्गेनिज्म ये रिटर्न कर देता तो दिक्कत हो जाती। क्योंकि अब ये जो एनिमल क्लास का रेफरेंस ए हमने यहां बनाया है ना ये ऑर्गेनिज्म क्लास के ऑब्जेक्ट को होल्ड नहीं कर सकता क्योंकि वो तो पेरेंट है उसका। राइट? तो ये है रिटर्न टाइप रूल। ये भी बहुत बेसिक रूल है। राइट? सिंपल ये क्या कहता है? जो रिटन टाइप यहां रखा है या तो वही रिटर्न टाइप सेम रख दो या फिर उसका नैरो टाइप रख दो। लेकिन पेरेंट टाइप मत रखना। उसका ब्रॉडर टाइप मत रखना। अब C++ में जब भी आप मेथड ओवराइड करते हो ना तो ज्यादातर मतलब 99% ऑफ़ द टाइम आप सेम का सेम रिटर्न टाइप यहां रखते हो। ठीक है? जैसे हमने आर्गुमेंट में देखा था ना वो तो आप बदल ही नहीं सकते। खैर जो आर्गुमेंट ऊपर है वो सेम नीचे होगा। रिटर्न टाइप भी ज्यादातर वही होता है। पर कभी कबभार ऐसा हो सकता है कि आपने यहां पे एक पेरेंट रिटर्न टाइप रखा जैसे कि एनिमल और यहां पे लेट्स से एक चाइल्ड रिटर्न टाइप रख दिया जैसे कि डॉग। ये कई बार हो सकता है। तो इसको हम बोलते हैं कोवेरियंस। तो ये टर्म याद रखना। इसको हम क्या बोलते हैं? को वेरियंस। बस यही है रिटन टाइप रूल। बस आपको ये भी फॉलो करना चाहिए। इसके बाद फटाफट से लास्ट सिग्नेचर रूल में जो लास्ट रूल है उसकी तरफ बढ़ते हैं जिसे हम बोलते हैं एक्सेप्शन रूल। ठीक है? अब देखो ये भी बहुत सिंपल है। ये भी बिल्कुल वही चीज कह रहा है। लेट्स से अ हमारे पास एक पेरेंट क्लास है। इस बार हम नॉर्मल इसको यूएमएल में ड्रॉ करते हैं। और उसके बाद हमारे पास उसकी एक चाइल्ड क्लास है। ठीक है? अब सपोज़ करो पेरेंट क्लास के पास एक मेथड है M1 जो एक एक्सेप्शन थ्रो करता है। अच्छा आपको C++ में एक्सेप्शन की हायरार्की पता है आपको पता है एक्सेप्शन एक ऑब्जेक्ट होती है। उसके अंदर मल्टीपल ऑब्जेक्ट्स होते हैं। तो एक बार अगर नहीं पता तो यहां पे हल्का सा देख लो। तो एक्सेप्शन की हायरार्की देख लेते हैं। सबसे पहले एक्सेप्शन में हमारे पास एक तो होता है लॉजिक एरर और उसके अंदर कुछ सब क्लासेस होती हैं। एक ऐसे होता है हमारे पास रन टाइम एरर और उसके अंदर कुछ सब सब क्लासेस होती हैं। तो ये कुछ तरह के एक्सेप्शनंस हैं C++ में और यूजर डिफाइंड एक्सेप्शनंस भी आप बना सकते हो। पर अभी हम एक्सेप्शनंस में नहीं जा रहे हैं। हम बस यहां आपको बता रहा हूं ताकि हम यहां पे उसको यूज़ कर सकें। तो लॉजिक एरर के अंदर जैसे आ जाती है आउट ऑफ रेंज एक्सेप्शन। राइट? और भी कई तरह कह सकते हैं मेमोरी एक्सेप्शन कुछ आ सकती है। आउट ऑफ रेंज आ सकती है। सेम रन टाइम एरर में भी बहुत सारी एक्सेप्शनंस आ सकती हैं। पर कहने का मतलब बस ये था कि ये जो है रन टाइम लॉजिकल एरर और रन टाइम एरर ये हमारी पेरेंट्स हैं और इनके अंदर ये सब इनके चाइल्ड्स हैं। ठीक है? तो अब आप सपोज़ करो मैं ये कह रहा था कि हमारे पास पेरेंट के पास एक फंक्शन है m1 तो सेम फंक्शन चाइल्ड के पास भी होगा। तो चाइल्ड भी उस m1 फंक्शन को ओवराइड करता होगा। राइट? अब ये रूल कहता है कि जो भी पेरेंट के पास m1 फंक्शन है लेट्स से वो एक एक्सेप्शन थ्रो करता है और वो एक्सेप्शन थ्रो करता है लेट्स से रन टाइम एरर। ठीक है? ठीक है? तो ये वाला जो चाइल्ड है ना या तो ये इसकी नैरो एक्सेप्शन को थ्रो करे या फिर ये सेम एक्सेप्शन थ्रो कर दे। तो M1 भी या तो रन टाइम एरर को ही थ्रो कर दे या फिर रन टाइम एरर की कोई चाइल्ड क्लास होगी ना उसको थ्रो करें लेकिन कभी भी उसकी ब्रॉडर एक्सेप्शन थ्रो ना कर दें। तो रन टाइम एरर की भी जो पेरेंट क्लास होगी लेट्स से उसको थ्रो ना कर दें। क्यों? सेम जो हमने उसमें सीखा था अभी अ इससे पहले रिटर्न टाइप एक्सेप्शन में रिटर्न टाइप रूल में वही है। लेट्स से हमारे पास एक क्लाइंट है। ठीक है? क्लाइंट पेरेंट को एक्सपेक्ट करता है और हमने गलत उसको चाइल्ड दे दिया। पेरेंट की जगह हमने उसको चाइल्ड दे दिया तो भी कोड फटना नहीं चाहिए। राइट? यही रूल था। अब लेट्स से क्लाइंट कैसे एक्सेप्शन हैंडल करता? तो क्लाइंट के पास एक ट्राई कैच ब्लॉक होता। तो क्लाइंट क्या करता? क्लाइंट के पास पहली बात तो सबसे पहले एक पी होता। ठीक है? पी क्या होता? इसका रेफरेंस होता जो इसको मिलता जो भी इसको ऑब्जेक्ट मिलता है, पेरेंट मिलता है, चाइल्ड मिलता है वो पी के रेफरेंस में सेव करता। ठीक है? तो बेसिकली क्लाइंट के पास एक ट्राई कैच ब्लॉक होता। तो सबसे पहले क्लाइंट क्या करता? ट्राई वाले ब्लॉक में पी में वो फंक्शन कॉल करता M1। ठीक है? और अगर कोई एक्सेप्शन आती तो उस एक्सेप्शन को कैच में हैंडल करता। अब क्लाइंट को तो ये पता होता ना कि कौन सी एक्सेप्शन आ सकती है। क्यों? क्योंकि उसको कॉन्ट्रैक्ट के बारे में पता है। तो ये जो पेरेंट क्लास है जो कि हो सकती है एक एब्स्ट्रैक्ट क्लास हो जो कि एक कॉन्ट्रैक्ट हो, एक इंटरफेस हो। तो क्लाइंट को उस कॉन्ट्रैक्ट के बारे में पता है कि ये जो M1 है ना ये रन टाइम एक्सेप्शन थ्रो करता है तो वो रन टाइम एरर का एक ऑब्जेक्ट बना लेता E। ठीक है? और उस ऑब्जेक्ट E में वो कैच में अंदर उसे कुछ एक्सेप्शन से हैंडल कर लेता किसी तरह। राइट? अब हमने क्या किया? लेट्स सपोज ये जो M1 है ना चाइल्ड का ये रन टाइम एरर का भी पेरेंट क्लास कोई थ्रो कर देता है। ठीक है? तो ये रन टाइम एरर थ्रो नहीं कर रहा। लेट्स से ये इसकी भी कोई पेरेंट क्लास पेरेंट एरर थ्रो कर रहा है। ठीक है? तो वो क्या है? अभी तो ऐसे तो C++ में रन टाइम एरर का कोई पेरेंट क्लास नहीं है। आप उसको एक्सेप्शन कह सकते हो इन जनरल। पर थोड़ा सा काम आसान करने के लिए हम ये मान लेते हैं कि जो पेरेंट क्लास का M1 है ना यह थ्रो कर रहा है आउट ऑफ रेंज एरर। ठीक है? तो जो आउट ऑफ रेंज एरर है यह एक तरह की लॉजिकल एरर है। ठीक है? तो यह हमारा एक लॉजिकल एरर है। तो मान लेते हैं m1 एक लॉजिकल एरर थ्रो कर रहा है और m ये जो चाइल्ड क्लास का m1 है वो लॉजिकल एरर थ्रो कर रहा है और पेरेंट का m1 आउट ऑफ रेंज एरर थ्रो कर रहा है। तो यहां पे उल्टा हो रहा है। तो ये बेसिकली क्या हो रहा है? ये जो चाइल्ड क्लास का अ मेथड है ना वो पेरेंट क्लास के मेथड का जो एक्सेप्शन थ्रो कर रहा है वो उसका भी ब्रॉडर एक्सेप्शन थ्रो कर रहा है व्हिच इज़ नॉट अलाउड। ठीक है? तो अब क्या होगा? देखो दिक्कत जब ये क्लाइंट इसको हैंडल करेगा अपने ट्राई कैच ब्लॉक में तो pm1 एक्सेप्शन थ्रो करेगा यानी कि रिजल्ट आ जाएगा कैच में जैसे ही कैच में आएगा कैच क्या करेगी यहां पे एक एक्सेप्शन क्लास का ऑब्जेक्ट है ई जो इसे मिल जाएगा लॉजिकल एरर अगर होगा तो या फिर आउट ऑफ मेमोरी एरर होगा तो वो ई को मिल जाएगा यानी कि अगेन ई एक रेफरेंस है जो एक ऑब्जेक्ट को रेफर करेगा चाहे वो पेरेंट क्लास का हो चाहे वो चाइल्ड क्लास का हो पर अगर वो पेरेंट क्लास का हुआ तो तो कोई दिक्कत नहीं है। आउट ऑफ मेमोरी एरर है यहां पे भी हमने लेट्स से सॉरी यहां पर भी फिर हमारा रन टाइम एरर नहीं होगा। यहां पर भी हम आउट ऑफ मेमोरी एरर होगा या आउट ऑफ रेंज एरर सॉरी आउट ऑफ रेंज एरर होगा। क्यों? क्योंकि हमने कहा था ये वाला जो पेरेंट क्लास का M1 है वो आउट ऑफ रेंज एरर थ्रो कर रहा है। और अगेन क्लाइंट के पास कॉन्ट्रैक्ट है पेरेंट का तो उसको पता है कि मेरे को आउट ऑफ रेंज एरर हैंडल करना है। तो आउट ऑफ रेंज एरर का वो एक्सेप्शन क्लास का ऑब्जेक्ट बना देता है ई। तो अब ये जो E है ये जो रेफरेंस है ये सिर्फ आउट ऑफ रेंज एरर के एक्सेप्शन को ही पॉइंट कर सकता है। पर अगर आपने इसको चाइल्ड क्लास का ऑब्जेक्ट दे दिया और फिर आपने P.m1 कॉल किया यानी कि ये वाला M1 कॉल हो जाएगा। और अगर ये वाला M1 कॉल हो गया तो वो तो वो लॉजिकल एरर थ्रो करेगा। पर अगेन ये जो E है ये लॉजिकल एरर को तो रेफर कर ही नहीं सकता क्योंकि ये तो आउट ऑफ रेंज का रेफर रेफरेंस ऑब्जेक्ट है। राइट? तो अगेन सेम प्रॉब्लम आ जाएगी कि ये तो पेरेंट क्लास है और ये चाइल्ड क्लास है। तो इसे रेफर नहीं कर सकता। इसलिए ये हमें करना पॉसिबल नहीं होना चाहिए। बेसिकली ये एक्सेप्शन रूल हमें मानना चाहिए। ठीक है? तो ये एक्सेप्शन रूल था। अब फटाफट से इन दोनों का हम कोड देख लेते हैं। आ जाओ स्क्रीन पे। चलो अब फटाफट रिटन टाइप का और एक्सेप्शन का और कोड देख लेते हैं। अगर आपको कोई भी प्रॉब्लम हुई होगी उसे समझने में तो ये कोड देख के एकदम बिल्कुल क्लियर हो जाएगा। यहां पे देखो मैंने अच्छे से कमेंट करके ये चीज लिखी हुई है। आप पढ़ सकते हो। अब वही कोड जो हमने बेसिकली वही एग्जांपल जो हमने किया था वही उसका कोड है। देखो हमने एक एनिमल क्लास बनाई और एक डॉग क्लास बनाई जो कि एक टाइप का एनिमल है। तो ये एक तरह की हायरार्की है। ठीक है? एनिमल और डॉग की। सेम अब हम क्या करते हैं? एक और हायरार्की बनाते हैं पेरेंट और चाइल्ड की। तो एक पेरेंट है और उसकी एक चाइल्ड क्लास है चाइल्ड। ठीक है? दोनों में एक मेथड है गेट एनिमल। राइट? अब ये जो पेरेंट का गेट एनिमल है ना ये एनिमल क्लास का एनिमल टाइप का रेफरेंस रिटर्न करता है। और ये जो अह चाइल्ड है ये क्या करता है? है गेट एनिमल इसका डॉग क्लास का रेफरेंस रिटर्न करता है। ठीक है? तो मैंने कहा था ये अलाउड है। ठीक है? क्योंकि ये पेरेंट एनिमल रिटर्न कर सकता है और ये चाइल्ड डॉग रिटर्न कर सकता है। क्योंकि इनकी भी हायरार्की ऐसे ही है कि एनिमल और डॉग जो है वो एक तरह का एनिमल है। राइट? इसी को हम कोवेरियंस बोलते हैं। अब ये जो चाइल्ड है ना यहां पे डॉग की जगह एनिमल भी रिटर्न कर सकता था। ये तो सेम हो गया। ये भी अलाउड है। पर क्या अलाउड नहीं है कि एनिमल की जगह एनिमल का भी कोई पेरेंट को रिटर्न कर दे। यहां पे एनिमल का कोई पेरेंट हमने बनाया नहीं है। पर लेट्स सपोज एनिमल का पेरेंट है लेट्स से ऑर्गेनिज़्म तो अगर ये ऑर्गेनज़्म को रिटर्न करे वो एक्सेप्ट नहीं होना चाहिए। आपको पता है हमने कोड में देखा ही था। बस सॉरी उसमें एग्जांपल में देखा ही था। तो सेम हमने क्लाइंट बनाया। उसको एक पेरेंट रेफरेंस दिया P प्राइवेट मेंबर है। उसको हमने कंस्ट्रक्टर में पुट कर दिया P। अब हमने इसमें एक फंक्शन बनाया टेक एनिमल जो कि इस पी का गेट एनिमल कॉल करता है। ठीक है? अब इस पी का जब वो गेट एनिमल कॉल करता है। अब मेन क्लास में आप देख लो। लो हमने एक पेरेंट का ऑब्जेक्ट बनाया। चाइल्ड का ऑब्जेक्ट बनाया और फिर एक क्लाइंट का ऑब्जेक्ट बनाया जिसमें हमने एक बार चाइल्ड पास कर दिया। तो अगर हमने इसको चाइल्ड पास किया तो ये जो क्लाइंट डॉट टेक एनिमल है ये ला के हमें क्या देगा? डॉग का इंस्टेंस ला कर के देगा। अगर हम यहां पेरेंट पास करते तो हमें ये ला के क्या देता? एन पेरेंट का बेसिकली एनिमल का इंस्टेंस ला करके देता। तो फटाफट से अगर हम इस कोड को चलाएं। अभी हमने यहां पे चाइल्ड क्लास पास किया हुआ है। तो अब सॉरी कट स्टार्ट। तो फटाफट से अगर हम इस कोड को चलाएं तो आप देख सकते हो यहां पर प्रिंट हो गया चाइल्ड रिटर्निंग डॉग इंस्टेंस। ठीक है? वही मैंने कहा था अगर हम इसकी जगह यहां पे पेरेंट पास कर देते। ओके? तो अगर हम इसकी जगह पेरेंट पास कर देते तो आप ध्यान से देखो कोड में क्या हुआ? पेरेंट रिटर्निंग एनिमल इंस्टेंस। तो एनिमल इंस्टेंस रिटर्न हो जाता। ठीक है? तो चलो अब नेक्स्ट कोड की तरफ मूव करते हैं। कट। हां जी। तो ये है एक्सेप्शन रूल की क्लास। अब देखो यहां पे मैंने पूरी की पूरी हायरार्की देख लिख दी है जो कि एक्सेप्शन एरर की होती है। देखो हमारे पास दो तरह के एरर होते हैं। एक्सेप्शनंस होते हैं। लॉजिक एरर और रन टाइम एरर और ये सब उसके सब क्लासेस हैं तीनों के अंदर। ठीक है? तो मैंने क्या बोला था? एग्जांपल में आते हैं वापस। हमारे पास एक पेरेंट क्लास है, चाइल्ड क्लास है। दोनों में एक फंक्शन है गेट वैल्यू। ठीक है? जब हम लिखते हैं C++ में नो एक्सेप्ट फॉल्स। यानी कि इसका मतलब ये एक एक्सेप्शन थ्रो करेगी। ठीक है? अब ये कौन सी एक्सेप्शन थ्रो कर रहा है? देखो, पेरेंट थ्रो कर रहा है लॉजिकल एरर एक्सेप्शन। यानी कि यह वाली एक्सेप्शन। अब ये जो चाइल्ड है ये या तो ये लॉजिकल एरर एरर एक्सेप्शन थ्रो करें या फिर उसकी कोई सब क्लास को थ्रो करें। तो यहां पे जो चाइल्ड है देखो आउट ऑफ रेंज एरर थ्रो कर रहा है व्हिच इज अ सब क्लास ऑफ़ लॉजिकल एरर क्लास। ये एक्सेप्टेबल है। पर क्लाइंट क्या सॉरी चाइल्ड क्या नहीं कर सकता? वो ये नहीं कर सकता कि जो चाइल्ड है ना वो आउट ऑफ रेंज की जगह इस लॉजिक एरर के भी पेरेंट को थ्रो कर दे या फिर लेट्स से रन टाइम एरर थ्रो कर दे। दे व्हिच इज़ कंप्लीटली डिफरेंट क्लास। तो अगर इसने रन टाइम एरर थ्रो कर दिया तो ये बहुत गलत हो जाएगा। क्यों? क्योंकि अगेन क्लाइंट उसे हैंडल नहीं कर पाएगा। तो सेम एग्जांपल है। क्लाइंट में हमने एक रेफरेंस बनाया। उसको कंस्ट्रक्टर में पास किया और उसमें एक मेथड बनाया टेक वैल्यू जो ट्राई कैच ब्लॉक में पुट होता है। सबसे पहले ट्राई ब्लॉक में वो क्या करता है? पी को गेट वैल्यू को कॉल करता है। और कैच में क्या करता है? अब देखो अगेन ये जो क्लाइंट है ना इसे पेरेंट के बारे में पता था। यानी कि पेरेंट के कॉन्ट्रैक्ट के बारे में पता था। तो इसे बताता है जो गेट वैल्यू मेथड है ना ये लॉजिक एरर थ्रो करेगा। तो मुझे लॉजिक एरर हैंडल करना है। तो ये जो इसलिए क्लाइंट है ये अपने कैच में लॉजिक एरर के लिए ऑब्जेक्ट बनाता है ई और उसको किसी तरह हैंडल कर देता है। ठीक है? पर हमने देखो मेन क्लास में क्या किया? हमने पहले पेरेंट का ऑब्जेक्ट बनाया। चाइल्ड का ऑब्जेक्ट बनाया। क्लाइंट का ऑब्जेक्ट बनाया जिसे हमने चाइल्ड पास किया। और देखो चाइल्ड क्या कर रहा है? हमारा आउट ऑफ रेंज एरर थ्रो कर रहा है। तो ये ई उसे हैंडल कर लेगा ईजीली। क्यों? क्योंकि ये जो ई है ये लॉजिक एरर का टाइप है और आउट ऑफ रेंज उसका सब टाइप है। तो ईजीली ई जो है वो रेफर कर सकता है लॉ आउट ऑफ रेंज एरर को। तो अब मैं बताता हूं चाइल्ड क्या नहीं कर सकता। देखो जो चाइल्ड है ना वो आउट ऑफ रेंज की जगह एक रन टाइम एरर थ्रो नहीं कर सकता। राइट? जैसे अभी हमने डिस्कस किया क्योंकि ये कंप्लीटली डिफरेंट क्लास है। ये जो अ कैच के अंदर ई है बेसिकली ये लॉजिक एरर का एक वो है रेफरेंस है। वो कभी भी रन टाइम एरर के ऑब्जेक्ट को रेफर नहीं कर सकता। वो सिर्फ लॉजिकल एरर या उसके सब टाइप को रेफर कर सकता है। ठीक है? अब हम एक काम करते हैं। पहले इस कोड को चला के देखते हैं। आउट ऑफ रेंज है। हमने यहां पे क्या किया? पेरेंट बनाया। चाइल्ड बनाया। एक क्लाइंट बनाया। इसको चाइल्ड पास कर दिया। उस क्लाइंट का टेक वैल्यू कॉल करा। यानी कि इस चाइल्ड का टेक वैल्यू कॉल होगा जो कि आउट ऑफ रेंज एरर थ्रो करेगा। तो आउट ऑफ रेंज जब एरर थ्रो करेगा तो कैच में आएगा और लॉजिकल एरर का रेफरेंस बना हुआ है जो इसे हैंडल कर लेगा और ये प्रिंट हो जाएगा। लॉजिकल एरर एक्सेप्शन ऑकर्ड। तो अगर हम इसे प्ले करें तो देखो लॉजिकल एरर एक्सेप्शन ऑकर्ड चाइल्ड एरर। ठीक है? अब यहां पे अगर हम पेरेंट भी पास कर देते तो भी कोई दिक्कत नहीं होती। क्यों दिक्कत नहीं होती? क्योंकि पेरेंट तो ऑलरेडी लॉजिक एरर थ्रो कर रहा है। तो अब अगर हम इस कोड को चलाते तो देखो लॉजिकल एरर एक्सेप्शन ऑकर पेरेंट एरर तो बिल्कुल सही है। तो अब देखते हैं हम क्या नहीं कर सकते। अब अगर हम क्या करते हैं कि चाइल्ड की जो क्लास है ना उसमें आउट ऑफ रेंज की जगह एक रन टाइम एरर थ्रो करा देते हैं। लेट्स सपोज़। ठीक है? तो अब रन टाइम एरर तो एक कंप्लीटली डिफरेंट क्लास हो गई। है ना? तो बेसिकली ये जो ई रेफरेंस है, ये इसे हैंडल नहीं करना चाहिए। तो देखते हैं क्या होता है। यहां पे फिर हम यहां पे हमने पेरेंट पास किया हुआ। यहां पे भी हम दोबारा से चाइल्ड पास कर देते हैं और इस कोड को अब दोबारा से रन करके देखते हैं। तो देखो ये फट गया। एक्सेप्शन आ गई। टर्मिनेटिंग ड्यू टू अनकॉट एक्सेप्शन ऑफ़ टाइप रन टाइम एरर। तो बेसिकली ये क्या कहना चाहता है? सेम चीज़ कि एक अनकॉट एक्सेप्शन है। आप लॉजिकल एरर तो एक्सेप्शन को हैंडल कर रहे हो। पर ये स्केच में जा ही नहीं रहा। क्योंकि यहां पे कोई लॉजिकल एरर तो आया नहीं है। रन टाइम एरर आया है। और रन टाइम एरर कोई लॉजिकल एरर का पार्ट तो है नहीं। तो ये इस कैच ब्लॉक में गया नहीं। इसके नीचे कोई और कैच ब्लॉक है ही नहीं। तो ये फट गया और एक्सेप्शन थ्रो कर दी। ठीक है? तो यही वो कोड था। आई होप आपको ये समझ आया होगा। चलो वापस से स्क्रीन पे आते हैं और आगे बढ़ते हैं। आई होप आपको सिग्नेचर रूल ढंग से समझ आ गया होगा। अब फटाफट से दूसरे रूल की तरफ मूव करते हैं। तो दूसरा रूल था हमारे पास प्रॉपर्टी रूल। ठीक है? अगर आपको सिग्नेचर रूल ढंग से समझ आ गया ना, तो ये भी बहुत ईज़ली समझ आ जाएगा। तो प्रॉपर्टी रूल के भी अंदर दो सबरूल्स हैं। तो फर्स्ट है हमारे पास क्लास इनवेरिएंट और दूसरा है हिस्ट्री कंस्ट्रेंट। अब ये बहुत थ्योरेटिकल नाम है। हो सकता है आपको नाम कॉम्प्लिकेट लगे। पर जब आप इनको पढ़ रहे हो समझ रहे हो आपको लगेगा बहुत सिंपल है। ठीक है? तो चलो सबसे पहले एक-एक करके दोनों देखते हैं। हम पहले देखेंगे क्लास इनवेरिएंट। ठीक है? अब क्लास इनवेरिएंट क्या कहता है? सबसे पहले हम समझते हैं इनवेरिएंट का मतलब क्या होता है? देखो इनवेरिएंट का मतलब होता है कोई भी ऐसा फैक्ट या कोई भी ऐसा रूल जो किसी क्लास के लिए हमेशा ट्रू होगा। ठीक है? तो वो क्लास इनवेरिएंट होता है। ठीक है? तो इनवेरिएंट को आप एक रूल कह सकते हो। एक रूल समझ सकते हो। ठीक है? तो ये कोई भी एक क्लास के लिए हमेशा ट्रू होना चाहिए। तो कोई भी एक रूल जो किसी क्लास के लिए हमेशा ट्रू होता है वो उसका इनवेरिएंट होता है। ठीक है? तो अब एक एग्जांपल लेते हैं। कहना क्या चाहता है? पहले वो समझते हैं। फिर एग्जांपल लेंगे। तो ये रूल क्लास इनवेरिएंट रूल ये कहना चाहता है कि लेट्स सपोज हमारे पास एक क्लास है पेरेंट। ओके? और इस पेरेंट क्लास के लिए एक इनवेरिएंट है। एक इनवेरिएंट है। मतलब एक रूल है। R1 वो एक रूल है। ठीक है? अब रूल क्या होता है? रूल कुछ नहीं होते। रूल आपके मन की चीज होती है जो आप चाहते हो वो क्लास फॉलो करें। कोई भी ऐसी चीज कोई भी ऐसा रूल जो आप चाहते हो वो क्लास फॉलो करें। रूल कोई C++ का ऑपरेशन या मेथड नहीं है। आप बस कमेंट में लिख देते हो यह क्लास यह रूल फॉलो करनी चाहिए और आप खुद से उसे फॉलो वो करवाते हो। ठीक है? तो वो आपकी रिस्पांसिबिलिटी होती है कि वो क्लास वो रूल फॉलो करे। अभी एग्जांपल में देखेंगे आपको समझ आ जाएगा। तो मैंने कहा एक पेरेंट क्लास है जिसका एक इनवेरिएंट यानी कि एक रूल है R1। तो जो भी उसकी चाइल्ड क्लास होगी ना चाइल्ड क्लास होगी वो उसकी रिस्पांसिबिलिटी होगी कि वो इस इनवेरिएंट रूल को फॉलो करे। फॉलो करने का मतलब क्या है? या तो इसको एज इट इज फॉलो करें या फिर इसको स्ट्रेंथन करें पर बिल्कुल भी वीक ना करें। तो जैसा हमने कहा कि हमारे पास एक इनवेरिएंट है R1 इस पेरेंट क्लास का। ठीक है? अब जो चाइल्ड क्लास है ना उसकी ये रिस्पांसिबिलिटी है कि वो पेरेंट क्लास के इस इनवेरिएंट को फॉलो करें। बिल्कुल भी इसे ब्रेक ना करे। इस रूल को बिल्कुल भी ब्रेक ना करें। तो अगर चाइल्ड क्लास इस रूल को ब्रेक कर देती है तो हम कहेंगे कि वो इनवेरिएंट प्रॉपर्टी फॉलो नहीं करती। यानी कि वो लिस्क ऑफ सब्स्टट्यूशन में सब्स्टट्यूटेबल नहीं है। मतलब चाइल्ड क्लास सब्स्टिट्यूटेबल नहीं है पेरेंट क्लास के लिए। ठीक है? आई मुझे नहीं लगता अभी इससे कुछ क्लियर हुआ होगा। तो अब इसको एग्जांपल से समझते हैं। ठीक है? ये एग्जांपल आपको बहुत ईज़ली समझ आ जाएगा। सपोज़ करो आपके पास एक क्लास है अकाउंट। ठीक है? जो कि एक बैंक बैंक अकाउंट है। तो इसको एक बार यूएमएल की तरह ड्रॉ करते हैं। ठीक है? तो आपके पास एक क्लास है लेट्स से अकाउंट। ओके? अब यह जो क्लास है ना अकाउंट इसके पास ऑब्वियसली एक वेरिएबल होगा बैलेंस क्योंकि एक बैंक अकाउंट है तो हर बैंक अकाउंट में एक बैलेंस मेंटेन होता है। ठीक है? अब ये जो अकाउंट क्लास है ना इसका एक रूल है। इस पूरी क्लास का एक रूल है जो मैं कमेंट करके उस क्लास के ऊपर लिख दूंगा कि बैलेंस कैन नेवर बी नेगेटिव। तो बैलेंस हमेशा पॉजिटिव होना चाहिए। शुड बी ग्रेटर दैन और इक्वल टू ज़ीरो हमेशा। ऑब्वियसली किसी भी बैंक अकाउंट का बैलेंस कभी भी नेगेटिव नहीं जा सकता। पर लेट्स से एक क्लास है जो इसे चीट करती है। तो उस क्लास को मैं नाम ही रखता हूं। लेट्स से चीट अकाउंट। ठीक है? और ये चीट अकाउंट क्या करता है? ये इस बैलेंस की प्रॉपर्टी को नेगेटिव सेट कर देता है। लेट्स से -1 कहीं भी कोड में कुछ कर देता है ऐसा कि वो नेगेटिव सेट हो पाए। ठीक है? तो मैं ये कहूंगा कि ये क्लास इनवेरिएंट को प्रॉपर्टी को फॉलो नहीं कर रहा है। क्योंकि अब कोई भी जो क्लाइंट है जो इस अकाउंट से इंटरेक्ट कर रहा होगा वो ये एक्सपेक्ट करेगा कि बैलेंस कभी नेगेटिव नहीं होगा। पर अगर आपने उसको चीट अकाउंट दे दिया तो उसमें तो नेगेटिव हो जाएगा। हो सकता है क्लाइंट फट जाए उस वजह से तो ये इनवेरिएंट प्रॉपर्टी को फॉलो नहीं करता। फटाफट से इसका कोड देख लेते हैं। तो ये है क्लास इनवेरिएंट का रूल। ठीक है? कोड सॉरी। सेम है बिल्कुल जो हमने अभी डिस्कस किया था। हमारे पास एक बैंक अकाउंट है। उसके पास एक बैलेंस प्रॉपर्टी है। ठीक है? और देखो यहां पे मैंने इनवेरियंस कैसे लिखा इनवेरिएंट बैलेंस कैन नॉट बी नेगेटिव। तो मैंने बस कमेंट लिख दिया। कुछ नहीं किया। तो अब ये मेरी जिम्मेदारी है कि मैं इस रूल को फॉलो करूं अपनी पेरेंट क्लास में। और हर चाइल्ड क्लास की जिम्मेदारी है कि वो इस रूल को फॉलो करें अपनी चाइल्ड क्लास में। तो मैंने क्या किया देखो अगेन एक कंस्ट्रक्टर में जब भी बैंक अकाउंट बनता है और तो ये जो बैलेंस आता है मैं चेक कर लेता हूं पहले ही कि वो नेगेटिव तो नहीं। अगर नेगेटिव है तो मैं इनवैलिड आर्गुमेंट थ्रो करता हूं। बैलेंस कांट बी नेगेटिव। और अगर नेगेटिव नहीं है तो ही मैं बैलेंस को बी असाइन करता हूं। सेम मैंने एक मेथड बना रखा है विथड्रॉ। तो जो भी आप अमाउंट डालते हो वो बैलेंस में से कट हो जाएगी। पर उससे पहले भी मैं सेम चीज चेक कर रहा हूं कि बैलेंस माइनस अमाउंट कभी भी नेगेटिव नहीं होना चाहिए। अगर है तो मैं रन टाइम एरर थ्रो कर दूंगा इनसफिशिएंट फंड। ठीक है? नहीं तो अगर ऐसा कुछ नहीं है यानी कि बैलेंस ज्यादा है अमाउंट से तो बैलेंस में से अमाउंट कट हो जाएगा और अमाउंट विथड्रॉन प्रिंट हो जाएगा। सिंपल। तो ये मैंने पेरेंट क्लास में फॉलो करवा दिया इस इनवेरिएंट को। अब लेट्स से कोई अकाउंट है चीट अकाउंट जो बैंक अकाउंट को इन वो करता है। इनहेरिट करता है। राइट? जैसे हमने डिस्कस किया था और ये क्या कर रहा है? इनवेरिएंट प्रॉपर्टी को ब्रेक कर रहा है। जो अलाउड नहीं था उसे अलाउ कर रहा है। तो अब देखो इसके विथड्रॉ फंक्शन में क्या करता है? जब भी कोई अमाउंट आता है वो सीधा बैलेंस में से कट कर देता है। नो मैटर अमाउंट जो है अगर बैलेंस से ज्यादा भी हुआ तो तो अगर आपके पास ₹100 हैं और आप कह रहे हो मुझे 200 निकालने हैं। तो ये चीट अकाउंट आपको निकालने देगा। ये सीधा क्या करेगा? एलएसपी को ब्रेक कर देगा। नेगेटिव बैलेंस को अलाउ कर देगा। तो यहां पे अमाउंट विथड्रॉन हो जाएगा सीधा बिना इसको चेक लगाए। ठीक है? तो ये ब्रेक कर रहा है क्लास इनवेरिएंट को जैसा कि हमने देखा। तो सेम मेन में आप देख सकते हो हम इसको यूज करके देख सकते हैं कि हम बैंक अकाउंट का ऑब्जेक्ट बनाएं और यहां पे बैंक अकाउंट की जगह अगर चीट अकाउंट करें और हम ₹100 बैलेंस की जगह दो ₹100 अगर बैलेंस होता और ₹200 निकाल लेते तो भी ये निकालने देता। राइट? तो यही वो क्लास इनवेरिएंट की प्रॉपर्टी को ब्रेक कर रहा है। अब नेक्स्ट प्रॉपर्टी देखते हैं फटाफट। तो यही था प्रॉपर्टी रूल में क्लास इनवेरिएंट। प्रॉपर्टी रूल का जो नेक्स्ट था जिसको हमने कहा था हिस्ट्री कंस्ट्रेंट उसको देख लेते हैं कि वह क्या होता है। हिस्ट्री कंस्ट्रेंट देखो यह भी बहुत सिंपल है। हिस्ट्री कंस्ट्रेंट क्या कहता है? हिस्ट्री कभी चेंज नहीं होनी चाहिए। तो एक बार जो पेरेंट क्लास ने कह दिया कि ये स्टेट है चाइल्ड क्लास उसी स्टेट को फॉलो करें। क्या मतलब इसका? देखो हमारे पास अगेन एक पेरेंट क्लास होती और एक चाइल्ड क्लास होती सी। ठीक है? पे अगेन हिस्ट्री कंस्ट्रेंट भी कोई ऑपरेटर या कोई मेथड ही नहीं होता। हम कमेंट करके बोलते हैं कि ये इस पेरेंट क्लास की एक कंस्ट्रेंट है। तो एक कंस्ट्रेंट हो सकता है। मतलब एक हिस्ट्री है जो एक स्टेट है जो पेरेंट क्लास चाहती है हमेशा ट्रू रहे हमेशा सच रहे। इसको कोई चेंज ना करे। लेकिन लेट्स से चाइल्ड ने उस हिस्ट्री को रिस्पेक्ट नहीं किया और चेंज कर दिया। ठीक है? तो हम कहेंगे हिस्ट्री कंस्ट्रेंट टूट गया। सीधा एग्जांपल समझेंगे। आपको बहुत बेटर समझ आएगा। ठीक है? यही अकाउंट वाला एग्जांपल लेके चलते हैं। ठीक है? तो क्या था हमारे पास अकाउंट वाले एग्जांपल में? हमारे पास एक अकाउंट क्लास थी। ठीक है? और उसके पास उसके अंदर एक मेथड हमारे पास बैलेंस था और लेट्स से एक मेथड था विथड्रॉ। ठीक है? तो क्या हुआ कि मैं कहता हूं कि हमारा जो अकाउंट क्लास है ना वो एक हिस्ट्री कंस्ट्रेंट सेट करती है। यानी कि मैं उसे अगेन एक कमेंट करके लिखता हूं कि ये जो विथड्रॉल क्लास है विथड्रॉल शुड ऑलवेज बी अलाउड। शुड ऑलवेज बी अलाउड। मतलब हमेशा विथड्रॉल होना चाहिए किसी भी क्लास से। ठीक है? ऐसा कभी ना हो कि आप अकाउंट से विथड्रॉ नहीं कर पा रहे। ये इस क्लास की प्रॉपर्टी है। इस क्लास का हिस्ट्री कंस्ट्रेंट है। ठीक है? तो हमेशा से विथड्रॉ अलाउ हुआ है। ये इसकी हिस्ट्री है और हमेशा रहना चाहिए। ऐसा ये कहता है। पर अगेन इसको ब्रेक करने के लिए लेट्स से एक चीट क्लास बनाते हैं। तो ये हमारा एक अगेन चीट अकाउंट हो गया। ठीक है? अब इस बार हमें एक चीट अकाउंट का नाम पता है। हमें इसको चीट अकाउंट लिखने की जरूरत नहीं है। हम इसे कहते हैं फिक्स्ड डिपॉजिट अकाउंट। कुछ याद आया? लिस्क ऑफ सब्स्टट्यूशन के मेन एग्जांपल में हमने इसको किया था। फिक्स्ड डिपॉजिट अकाउंट। ठीक है? अब फिक्स्ड डिपॉजिट अकाउंट भी एक तरह का अकाउंट है। पर उसमें विथड्रॉल तो पॉसिबल होता ही नहीं है। ठीक है? तो हम क्या करते? हम जनरली वही करते जो हम उसमें किया था। एग्जांपल में हम विथड्रॉल को ओवराइड तो करते पर इसके ओवराइड इस के बॉडी के अंदर हम यहां पे एक एक्सेप्शन थ्रो कर देते थ्रो न्यू सम एक्सेप्शन। ठीक है? ये कहते हुए कि ये तो पॉसिबल ही नहीं है। पर यहां पे हमने पता है क्या किया? हमने हिस्ट्री कंस्ट्रेंट को ब्रेक कर दिया। क्योंकि अकाउंट ने कहा था कि वो कभी भी विथड्रॉल अलाउड हमेशा रहना चाहिए। पर फिक्स्ड डिपॉजिट अकाउंट ने उसको ब्रेक कर दिया। तो यानी कि ये लिस्क ऑफ सब्स्टट्यूशन प्रिंसिपल के हिसाब से सब्स्टट्यूटेबल चाइल्ड क्लास नहीं है। इसलिए हमारा जो मेन एग्जांपल था उसमें हमने जब ये शो किया था तो हम यही कह रहे थे कि वो चाइल्ड क्लास सब्स्टट्यूटेबल नहीं है। जिसको ठीक करने के लिए हमने फिर मल्टीपल इंटरफेस बनाए थे। अब वहां पे आप याद कर सकते हो वो चाइल्ड क्लास इसलिए सब्स्टट्यूटेबल नहीं थी क्योंकि वो हिस्ट्री कंस्ट्रेंट को ब्रेक कर रही थी। राइट? अब याद रखना कि वो क्यों ब्रेक कर रही थी। मतलब बेसिकली क्यों सब्स्टट्यूटेबल नहीं थी अपने पेरेंट क्लास के। ठीक है? तो यही कहता है हमारा हिस्ट्री कंस्ट्रेंट जो हमने लिखा है फट जो हमने यहां पे समझा है फटाफट उसका कोड देख लेते हैं। सो ये रहा हिस्ट्री कंटेंट का कोड। ठीक है? सेम हमने क्या किया? बैंक अकाउंट बनाया। उसमें बैलेंस है और यहां पे हमारे पास एक विथड्रॉल फंक्शन है। और हिस्ट्री कंस्टेंट हमने क्या लिख दिया? विथड्रॉल शुड बी अलाउड। हमेशा अलाउड होना चाहिए। तो यहां पे तो सेम फंक्शन है। देखो अलाउड है। राइट? फिर हमने क्या किया? एक फिक्स्ड डिपॉज़िट अकाउंट बनाया ऑफ टाइप बैंक अकाउंट। और यहां पे जब भी विथड्रॉ कॉल होता है, हमने क्या किया? हमने रन टाइम एरर थ्रो कर दिया। क्योंकि फिक्स्ड डिपॉज़िट अकाउंट में विथड्रॉ नहीं होना चाहिए। पर ये करते ही हमने क्या किया? एलएसपी को ब्रेक कर दिया। क्यों? क्योंकि हमने हिस्ट्री कंस्ट्रेंट को सॉरी हिस्ट्री कंस्ट्रेंट को ब्रेक कर दिया यहां पे। ठीक है? तो ये आप देख सकते हो ये एग्जांपल है हिस्ट्री कंस्ट्रेंट का। इसके बाद मेन फंक्शन में आप वही करो कि हमने एक बैंक अकाउंट बनाया न्यू बैंक अकाउंट टाइप का और उसमें विथड्रॉ किया। यहां पे विथड्रॉ हो जाएगा। पर अगर हम यहां पे फिक्स्ड डिपॉजिट अकाउंट अगर पास करेंगे तो यहां पे एक्सेप्शन आ जाएगा। अब मान लो ये क्लाइंट है मेन फंक्शन। ये क्लाइंट तो ये एक्सेप्शन को एक्सपेक्ट नहीं कर रहा था। राइट? क्लाइंट क्या एक्सपेक्टे कर रहा था कि जब भी मैं विथड्रॉ करूं विथड्रॉ हो जाए। पर इसकी वजह से विथड्रॉ नहीं हो पा रहा क्योंकि इसने एलएसपी को ब्रेक कर दिया। ठीक है? चलो तो आई होप आपको ये वाला प्रॉपर्टी रूल भी समझ आया होगा। हिस्ट्री कंस्ट्रेंट। हिस्ट्री कंस्ट्रेंट में एक छोटी सी चीज और बताऊं। बड़ी इंटरेस्टिंग है। आपको इम्यूटेबल क्लास पता है क्या होती है? इम्यूटेबल क्लास। एक ऐसी क्लास जिसका कोई चाइल्ड जिसको कोई इन्हहेरिट ना कर पाए। ठीक है? उसे हम इम्यूटेबल क्लास बोलते हैं। कि उसको इम्यूटेबल मतलब दैट कैन नॉट बी चेंज्ड। ठीक है? और ऐसे ही एक इम्यूटेबल मेथड्स होते हैं। ठीक है? ऐसे मेथड्स जिसको कोई ओवराइड ना कर पाए वो इम्यूटेबल मेथड होते हैं। ठीक है? तो अगर आपने किसी क्लास के आगे C++ में फाइनल लगा दिया तो वो इम्यूटेबल क्लास बन जाएगी। सेम अगर किसी मेथड के आगे फाइनल लगा दिया तो वो इम्यूटेबल मेथड बन जाएगा। तो अगर क्लास इम्यूटेबल है उसको कोई एक्स उसको कोई इन्हहेरिट नहीं कर सकता और मेथड इम्यूटेबल है तो उसको कोई ओवराइड नहीं कर सकता। तो यहां पे हिस्ट्री कंस्ट्रेंट में एक बात याद रखना अगर एक पेरेंट क्लास ने किसी-किसी बिहेवियर को या किसी-किसी प्रॉपर्टी को अपनी इम्यूटेबल बोला है कि उसे आप चेंज ना करो और अगर चाइल्ड क्लास उसको म्यूटेबल बना दे तो ये भी हिस्ट्री कंस्ट्रेंट का एक ब्रेकिंग रूल है। ये ब्रेक हो रहा है हिस्ट्री कंस्ट्रेंट यहां पे। याद रखना। तो कभी भी ऐसा ना करना कि एक चाइल्ड क्लास है जो किसी पेरेंट क्लास के इम्यूटेबल मेथड को या इम्यूटेबल वेरिएबल को म्यूटेबल बना दे। ठीक है? तो इट वाज़ जस्ट अ फैक्ट जो आप कभी कोड में हो सकता है बहुत बार देखते हो ये फॉलो नहीं होता है। तो आप याद रखना कभी भी ऐसा कोड देखो आपको पता है यहां पे हिस्ट्री कंस्ट्रेंट फॉलो नहीं हो रहा। चलो अब हमने क्या-क्या देख लिया? हमने सिग्नेचर रूल देख लिया। हमने प्रॉपर्टी रूल देख लिया। अब बस लास्ट रूल रह गया है जिसको हम बोलते हैं मेथड रूल। तो फटाफट से ये भी देख लेते हैं और खत्म। मेथड रूल के अंदर भी दो सबरूल्स होते हैं। एक होता है प्री कंडीशन और एक होता है पोस्ट कंडीशन। ठीक है? अब क्या होती है प्री कंडीशन? पोस्ट कंडीशन देखते हैं फटाफट। देखो ओके। स्टार्ट करते हैं। तो सबसे पहले देखते हैं प्री कंडीशन। देखो प्री कंडीशन कोई भी ऐसी कंडीशन होती है जो किसी मेथड के रन होने से पहले फॉलो होनी चाहिए। ठीक है? तो फॉर एग्जांपल हमारे पास अ एक पेरेंट क्लास है P उसके पास एक मेथड है M1 और अगर हमने इसके ऊपर एक प्री कंडीशन लगाई है। प्री कंडीशन अगेन कोई ऑपरेटर नहीं है, कोई मेथड नहीं है। हम कमेंट करके लिखते हैं और वो हमारी जिम्मेदारी होती है सब फॉलो करना। तो अगर हमने इसके ऊपर कोई प्री कंडीशन लगाई है तो M1 के एग्जीक्यूट होने से पहले वो प्री कंडीशन फॉलो होनी चाहिए। ठीक है? तो प्री कंडीशन रूल ये कहता है कि लेट से हमारे पास एक पेरेंट क्लास ऑब्जेक्ट है P उसका एक चाइल्ड है हमारे पास C तो अगर M1 जो कि P का एक पे मेथड है उसके ऊपर कोई प्री कंडीशन लगी है तो ये जो चाइल्ड है जब ये M1 को ओवराइड करेगा तो ये इस प्री कंडीशन को एज इट इज़ फॉलो करवा सकता है या उसको और वीक कर सकता है पर स्ट्रेंथन स्ट्रेंथन नहीं कर सकता। स्ट्रेंथन करने का मतलब क्या होता है? किसी कंडीशन को उस कंडीशन में और कंस्ट्रेंट्स ऐड नहीं कर सकता। क्या मतलब है? अभी एग्जांपल के वे में देखेंगे। आपको बहुत ईजीली समझ आ जाएगा। चलो देखते हैं। ठीक है? ये एग्जांपल बहुत ही वेग एग्जांपल मैं लूंगा इसको इजीली समझाने के लिए। और इसके बाद हम एक बेटर एग्जांपल लेंगे। अगर आप ये समझ गए तो वो एग्जांपल और ज्यादा अच्छे से समझ आएगा। ठीक है? तो सबसे पहले एक वेग एग्जांपल। ठीक है? तो अगेन मैं एक ऐसे एग्जांपल लेता हूं। हमारे पास एक पेरेंट क्लास है। ठीक है? उस क्लास के पास एक मेथड है m1 और वैसे ही हमारे पास एक चाइल्ड क्लास है जो इसे ओवराइड करती है तो उसके पास भी मेथड आ जाएगा m1 ठीक है अब इसके ऊपर एक प्री कंडीशन लगी है ठीक है तो मैं इस m1 मेथड को यहां ड्रॉ कर रहा हूं ठीक है अब ध्यान से देखना तो ये मेथड कुछ इस तरह दिखता है वॉइड m1 जो एक नंबर लेता है अ ऑब्वियसली अगर ये नंबर ले रहा है तो मैं इसको इसको लिखना पड़ेगा इंट नम और उस पे कुछ-कुछ करता है। ठीक है? सबसे पहले मैंने यहां पे एक प्री कंडीशन लिख दी। यहां पे प्री कंडीशन लिख देते हैं। तो मैं ऐसे लिखता हूं प्री कंडीशन। अ ये जो नंबर है शुड ऑलवेज बी ग्रेटर दैन इक्वल टू ज़ीरो एंड शुड ऑलवेज बी लेस दैन इक्वल टू 5 यानी कि ज़ीरो से फाइव के बीच में रहना चाहिए। तो अगर वो नहीं रहेगा तो मैं यहां पे एक्सेप्शन भी थ्रो कर दूंगा। तो मैं ऐसे चेक कर लूंगा। लेट्स से इफ यह जो नम पास हुआ है इज़ लेस दैन नॉट इक्वल टू हां इफ लेस दैन 0 और इफ नम इज ग्रेटर दैन 5 तो मैं यहां पर क्या करता हूं थ्रो कर देता हूं कोई एक्सेप्शन को तो थ्रो सम लेट्स से लॉजिकल एरर एनीथिंग राइट तो ये मैंने क्यों किया मैटर नहीं करता आप बस इसको समझो अभी तो एक मेथड है m1 जो पेरेंट के अंदर आता है वो एक नंबर लेता है और वो अगर नंबर ज़ीरो से छोटा है या पांच से बड़ा है तो एक्सेप्शन थ्रो कर देगा तो मेरी प्री कंडीशन ही ये है तो जो भी आप इसको नंबर दो ज़ीरो से फाइव के बीच में दो ठीक है अब जब सेम मेथड मैं चाइल्ड में बनाऊंगा ूंगा m1 तो मैं इसको ओवराइड करूंगा। तो ओवराइड करके मैं क्या करूंगा? मैं सेम ऐसे लिखूंगा वॉइड m1 वो भी नंबर लेगा और वो भी ये सेम कंडीशन लगाएगा। राइट? अब मैं इस प्री कंडीशन को एज इट इज़ यहां पे उतार सकता हूं। तो मैं भी यहां कह सकता हूं भाई सेम ये जो नंबर है ये ज़ीरो से बड़ा होना चाहिए एंड फाइव से छोटा होना चाहिए। तो ये भी अलाउड है। या फिर मैं इसको और वीक कर सकता हूं। मैं कह सकता हूं ज़ीरो से बड़ा होना चाहिए। पर फाइव की जगह लेट्स से 10 से छोटा होना चाहिए। तो मैंने 0 से 5 एक रेंज थी। मैंने 0 से 10 कर दी रेंज। ठीक है? ये भी चल जाएगा। तो इस कंडीशन को मैं सेम यहां उतार लूंगा। बस इस नम ग > 5 की जगह मैं लिख दूंगा नम > 10 तो मैं एक्सेप्शन थ्रो कर दूंगा। तो अच्छा मैं कह रहा हूं ये चल जाना चाहिए। क्यों चलना चाहिए? अब इमेजिन करो हमारे पास एक क्लाइंट है। ठीक है? जो कि अगेन पेरेंट क्लास का ऑब्जेक्ट एक्सपेक्ट कर रहा था। आपने उसे चाइल्ड का दे दिया। तो आप समझ ही गए होंगे। ठीक है? तो जब वो क्लाइंट पेरेंट क्लास का ऑब्जेक्ट एक्सपेक्ट कर रहा था ना तो वो क्या करता उस पे M1 कॉल करता। जब वो M1 कॉल करता उसे बाय द कॉन्ट्रैक्ट ये पता होता कि मुझे M1 को जो नंबर देने हैं ना वो ज़ीरो से फाइव के बीच में देने हैं। अगर मैंने उसके आगे पीछे के नंबर दिए तो फट जाएगा कोड तो मुझे दिक्कत हो जाएगी। तो क्लाइंट को ये बात ऑलरेडी पता है। लेकिन मैंने क्लाइंट को पेरेंट की जगह चाइल्ड का ऑब्जेक्ट पास कर दिया। और चाइल्ड जो है वो लेट से ज़ीरो से 10 के बीच में चीजें अलाउ कर रहा है। तो जैसे ही मैंने चाइल्ड का ऑब्जेक्ट पास किया क्लाइंट को और ज़ीरो से 10 के बीच में अलव कर रहा है। तो क्लाइंट तो पहले ही बहुत ज्यादा कंसर्न है कि मुझे ज़ीरो से अ नंबर जो है फाइव तक का रखना है। ठीक है? तो वो अभी भी ज़ीरो से फाइव का रखेगा। चाइल्ड को कोई दिक्कत ही नहीं है। चाइल्ड ज़ीरो से 10 तक एक्सेप्ट कर सकता है। तो फाइव भी कर ही लेगा। पर अगर गलती से क्लाइंट ने सिक्स, सेवन या एट दे दिया तो भी क्लाइंट उसे तो भी चाइल्ड उसे हैंडल कर लेगा क्योंकि वो तो 10 तक हैंडल कर सकता है तो भी क्लाइंट नहीं फटेगा। तो बेसिकली कोई दिक्कत नहीं है। आप अगर उसको थोड़ा सा वीक भी कर दो कंडीशन को पर कभी भी आप कंस्ट्रेंट नहीं कर सकते। तो अगर मैंने इस कंडीशन को और स्ट्रिक्ट कर देता कि लेट्स से मैं कहता ज़ीरो से 10 नहीं मैं कह रहा हूं भाई ज़ीरो से सिर्फ थ्री तक अलाउड होना चाहिए। पर क्लाइंट तो अगर यहां पे फोर दे देता जो कि अलाउड होना चाहिए पेरेंट की तरफ से। पर चाइल्ड उसे अलाउ नहीं करता। तो अगेन ये लिस्क ऑफ सब्स्टट्यूशन को ब्रेक कर देता। तो ये एक तरीके का एग्जांपल है जिससे आप इसे समझ सकते हो प्री कंडीशन को। पर ये एक बेटर एग्जांपल नहीं है। राइट? एक बेटर एग्जांपल क्या हो सकता है पता है? देखो बेटर एग्जांपल ये हो सकता है जो प्रैक्टिकल एग्जांपल है। सपोज़ हमारे पास एक यूजर क्लास है। ठीक है? और यूजर क्लास के पास एक अ फंक्शन है। लेट्स से चेंज पासवर्ड या लेट्स से नॉट चेंज क्रिएट पासवर्ड। ठीक है? क्रिएट पासवर्ड। ये फंक्शन है। ठीक है? और मैं अगेन यहां पे एक प्री कंडीशन लगा देता हूं कि पासवर्ड की जो लेंथ है वो शुड बी ग्रेटर दैन इक्वल टू 8। ये कंडीशन है। ठीक है? अब लेट्स सपोज इसकी एक चाइल्ड क्लास है जिसका नाम है एडमिन यूजर। तो अब ये क्योंकि इसकी चाइल्ड क्लास है तो मैंने कहा इसके पास भी एक नेम सिंपल मेथड होगा क्रिएट पासवर्ड। और वो भी इसी प्री कंडीशन को फॉलो करेगा। यानी कि वो भी इस प्री कंडीशन को फॉलो करना चाहिए कि पासवर्ड की लेंथ शुड बी ग्रेटर दैन इक्वल टू 8। पर अगर लेट्स से वो इस प्री कंडीशन को एज़ इट इज़ फॉलो ना करके थोड़ा वीक भी कर दे कि लेट्स से पासवर्ड लेंथ नॉट ग्रेटर दैन इक्वल टू 8 बल्कि ग्रेटर दैन इक्वल टू सिक्स। तो भी कोई दिक्कत नहीं होगी किसी क्लाइंट को जो ये कोड यूज़ कर रहा है। ठीक है? क्योंकि क्लाइंट को यूजर का कॉन्ट्रैक्ट पता है। क्लाइंट को पता है मुझे मिनिमम पासवर्ड की लेंथ एट रखनी है। तो अगर मैंने गलती से क्लाइंट को अ एडमिन यूजर भी पास कर दिया तो क्लाइंट क्या करेगा? पासवर्ड एट लेंथ का बनाएगा तो भी एडमिन यूजर अलाउ कर देगा क्योंकि वो छह से ऊपर का अलव करता है। अब गलती से क्लाइंट ने आठ की जगह सात का पासवर्ड बना दिया तो भी एडमिन यूजर एक्सेप्ट कर लेगा। मतलब कोड फटेगा नहीं। आप समझ रहे हो कोई दिक्कत नहीं होगी। अब अगेन ये ना यूज़ केस पे डिपेंड करता है। हो सकता है किसी एप्लीकेशन का यूज़ केस ऐसा हो कि पासवर्ड स्ट्रिक्टली एट ही होना चाहिए। तो उस केस में ये जो चाइल्ड है ये प्री कंडीशन को एज इट इज फॉलो करना चाहिए। ना कम ना ज्यादा। ठीक है? पर इन जनरल मैं बोल रहा हूं कि आप प्री कंडीशन को थोड़ा सा वीक कर सकते हो पर उसे स्ट्रेंथन नहीं कर सकते। ये एक बेसिक प्रिंसिपल है। ठीक है? चलो इसी का ही फटाफट से कोड देख लेते हैं। तो देखो ये वही कोड है। हमारे पास यूजर की एक क्लास है जिसकी हमने प्री कंडीशन लिख दी। पासवर्ड मस्ट बी एट कररेक्टर लॉन्ग। और हमने सेट पासवर्ड का मेथड बनाया जो पासवर्ड लेता है और चेक करता है एट का है या नहीं है। अगर एट से कम का है तो इनवैलिड आर्गुमेंट थ्रो कर देते हैं। सेम फिर हमने क्या किया? एडमिन यूजर बनाया ऑफ यूजर टाइप और इसमें भी सेट पासवर्ड का मेथड है जो ओवराइड किया हमने पर इसमें प्री कंडीशन थोड़ी सी वीक कर दी कि छह कररेक्टर्स अलाउड है तो अगर छह से कम होगा तो ही ये इनवैलिड आर्गुमेंट थ्रो करेगा नहीं तो पासवर्ड को सेट करने देगा तो ये एग्जांपल है प्री कंडीशन का और अगर आप प्री कंडीशन फॉलो कर रहे हो तो अगेन आप लिस्कॉफ में सब्सीट्यूटेबल हो। तो चलो फटाफट नेक्स्ट कंडीशन देखते हैं। तो अगर आपको प्री कंडीशन समझ आ गई तो आपको जो अगली पोस्ट कंडीशन है वो तो बहुत ईजीली समझ आ जाएगी क्योंकि वो जस्ट इसके उल्टी है। देखो पोस्ट कंडीशन वो कंडीशन होती है जो किसी मेथड के रन होने के बाद ट्रू होनी चाहिए या मेथड के रन होने के बाद सेटिस्फाई होनी चाहिए। ठीक है? और पोस्ट कंडीशन कहता भी वही है जो एकदम प्री कंडीशन कहता है। जस्ट उसका उल्टा कि हमारे पास लेट्स से एक पेरेंट क्लास है P और लेट्स से उसकी एक चाइल्ड क्लास है C और पेरेंट के पास एक मेथड है M1 चाइल्ड के पास भी सेम मेथड होगा M1 तो पोस्ट कंडीशन कहता है कि सपोज़ इस M1 पे एक पोस्ट कंडीशन लगी हुई है। ठीक है? तो चाइल्ड क्लास या तो वो पोस्ट कंडीशन को एज इट इज लगा दे अगेन या तो उसे और ज्यादा कंस्ट्रेंट कर दे पर उसे कभी भी वीक ना करें। तो एग्जैक्टली प्री कंडीशन का उल्टा है। वो कह रहा था वीक अलाउड है पर सीरियसली उसको और कंस्ट्रेंट ना करें। पर ये कह रहा है कंस्ट्रेंट कर दे पर वीक अलाउड नहीं है। ठीक है? अब आप कहोगे इसका कोई एग्जांपल इसका एग्जांपल देते हैं। उससे बहुत बेटर समझ आएगा। चलो इसका बहुत नॉर्मल सिंपल एग्जांपल रखते हैं। ठीक है? सपोज़ करो वापस से अपने कार वाले एग्जांपल पे चलते हैं। बहुत टाइम से कार वाला एग्जांपल नहीं उठाया। सपोज़ करो हमारे पास है एक कार। ठीक है? ये पेरेंट क्लास है और कार के पास एक मेथड है जिसे हम बोलते हैं ब्रेक। अब नॉर्मली ब्रेक लगने से क्या होगा? कार की स्पीड कम होनी चाहिए। तो यही हमने यहां पे पोस्ट कंडीशन में लिख दिया कि आफ्टर अप्लाइंग ब्रेक कार शुड स्लो डाउन। तो यह कंडीशन है भाई कि जो भी ब्रेक फंक्शन को ओवराइड कर रहा है कार हमेशा स्लो डाउन हो जानी चाहिए। ठीक है? तो बेसिकली हो सकता है ये जो पेरेंट क्लास है कार ये ब्रेक को ऐसे एग्जिट करती हो कि यहां पे क्या करती हो? स्पीड को जो भी यहां पे स्पीड होगी उसको 20 से डिक्रीज कर देती हो। राइट? कुछ भी हो सकता है। ये सिर्फ इमेजिनेशन पे चल रहा है। मैं कह रहा हूं कि ऐसा सपोज वह करती होगी। ठीक है? तो चलो ये हो गई कार क्लास। अब इसी की एक चाइल्ड क्लास बनाते हैं। लेट्स से चाइल्ड क्लास जो है वो है हमारे पास इलेक्ट्रिक कार। वो भी एक तरह की कार ही है। राइट? अब मैंने कहा वो भी इसी प्री कंडीशन को फॉलो करें कि जब भी वो ब्रेक को एग्जीक्यूट करे यानी ब्रेक को ओवराइड करे तो स्पीड ऑफ द कार शुड डिक्रीज। तो स्पीड शुड डिक्रीज। पर वो इसे और स्ट्रेंथन कर सकती है। वो ये कह सकती है स्पीड तो डिक्रीज होगी होगी लेकिन जो चार्जिंग है ना वो इंक्रीस भी हो जाएगी साथ-साथ क्योंकि इलेक्ट्रिक कार में ऐसा हो सकता है। राइट? जब आप ब्रेक करते हो उस ब्रेक से चार्ज इंक्रीस हो सकता है थोड़ा सा। तो ये उसको और कंस्ट्रेंट कर रहा है कि ब्रेक स्पीड तो कम होगी ही होगी। वो तो हमेशा ट्रू है। साथ ही साथ मैं कह रहा हूं थोड़ी सी चार्जिंग मैं इंक्रीस कर दूंगा। कोई दिक्कत नहीं है। अभी भी ये लिस्क ऑफ सब्स्टट्यूशन प्रिंसिपल को फॉलो कर रहा है। पोस्ट कंडीशन को फॉलो कर रहा है। क्योंकि ये उसको बस स्ट्रेंथन कर रहा है। पर बिल्कुल वीक नहीं कर सकता। अगर यह कह रहा है ब्रेक कि स्पीड कम होगी और इलेक्ट्रिक कारयर कह रही है ब्रेक से स्पीड कम नहीं हो रही तो ये बहुत बड़ी दिक्कत है। क्योंकि जो यहां पे क्लाइंट है जो कि एक एक्चुअल यूजर है जो गाड़ी चलाने आया है उसे पता है मैं गाड़ी पे ब्रेक दबाऊंगा। गाड़ी रुक जाएगी। पर अगर हम उसकी गाड़ी क्लास की जगह इलेक्ट्रिक कार पास कर दी तो उसमें तो वो ब्रेक दबाएगा तो गाड़ी तो रुकेगी नहीं। तो ये तो जानलेवा खतरा हो सकता है। राइट? तो ये लिस्का ऑफ सब्स्टट्यूशन फॉलो नहीं करता उस केस में। दैट्स इट। इसका भी फटाफट से कोड देख लेते हैं। तो ये रहा पोस्ट कंडीशन का कोड। सेम है। बिल्कुल। हमने कार लिया, स्पीड लिया और एक्सलरेट और ब्रेक दो फंक्शन बनाए। ब्रेक पे हमने लिख दिया स्पीड मस्ट रिड्यूस आफ्टर ब्रेक। उसके बाद हमने क्या किया? एक हाइब्रिड कार बनाई ऑफ टाइप कार। इलेक्ट्रिक कार भी बना सकते थे। पर सपोज़ करो सेम यहां जो ब्रेक का मेथड है जो ओवराइड कर रहा है उस पे वो पोस्ट कंडीशन हमने दो कर दी। एक तो स्पीड मस्ट रिड्यूस, एक चार्ज मस्ट इंक्रीज़। तो यहां पे देखो हमने स्पीड माइनस कर दी 20। यहां पे भी हमने माइनस कर दी थी 20 लेकिन चार्ज को हमने 10 से बढ़ा दिया। कोई दिक्कत नहीं है। जब भी ये जो क्लाइंट है जब ये गाड़ी चलाएगा चाहे वो हाइब्रिड कार चलाए चाहे वो नॉर्मल कार चलाए। ब्रेक दबाने से स्पीड हमेशा कम हो जाएगी जो बेसिक पोस्ट कंडीशन थी। उसके बाद हाइब्रिड कार में चाहे कुछ भी होता रहे। ब्रेक दबाने के बाद ब्रेक कम हो गई ना एक बार। उसके बाद वो चार्ज इंक्रीस करे, वो एसी ते करे, कम करे, कुछ भी करे हमें मतलब नहीं है। लेकिन जो ब्रेक का मेन पोस्ट कंडीशन थी वो फुलफिल हो रही है। राइट? तो समझ आया आपको? तो दैट्स ऑल अबाउट लिस्क ऑफ सब्स्टट्यूशन प्रिंसिपल। आई होप अब आपको लिस्क ऑफ तो अच्छे से क्लियर हो गया होगा। इस पे हमने सबसे ज्यादा टाइम लगाया है। मुझे नहीं लगता कोई और इसको इतना टाइम देता होगा। पर अब आप लिस्क ऑफ सब्स्टट्यूशन प्रिंसिपल में कभी गलती नहीं करोगे। अब आप हमेशा करेक्टली आइडेंटिफाई कर लोगे कि कोई क्लास कोई भी सब क्लास क्या सब्स्टट्यूटेबल है अपने पेरेंट क्लास के। ठीक है? तो यही कुछ गाइडलाइंस थी जो हमेशा फॉलो करनी चाहिए। आपको अगर मैं मोटा-मोटा कंक्लूड करूं तो आपको देखना चाहिए कोई भी एक चाइल्ड क्लास किसी भी पेरेंट क्लास के सब्स्टिट्यूटेबल तब नहीं रह जाती अगर वो अपने पेरेंट क्लास के जो मेथड है उसको ओवराइड तो करती है पर लेट्स से उसे ढंग से ओवराइड नहीं करती मतलब उसको एक्सेप्शन थ्रो कर देती है ओवराइड में या फिर एक्सेप्शन की जगह एंप्टी छोड़ देती है पूरा का पूरा मेथड राइट कि मैं ओवराइड कर नहीं सकती जैसे हमने अकाउंट का एग्जांपल लिया था तो हमारे पास क्या था फिक्स्ड डिपॉजिट अकाउंट था वो विथड्रॉ को ओवराइड नहीं कर सकता तो उसने एक्सेप्शन थ्रो कर दी यानी कि वो अच्छी चाइल्ड क्लास नहीं वो लिसक ऑफ में सब्सीट्यूट नहीं कर सकती। अगर वो उसको एक्सेप्शन थ्रो ना करके उसे खाली छोड़ देती विथड्रॉ लिख के खाली छोड़ देती तो भी वो अच्छी चाइल्ड क्लास नहीं होती। राइट? उसे भी वो लिस्क ऑफ में सब्स्टिट्यूट नहीं कर पाती। इसके अलावा और क्या हो सकता है? लेट्स से वो चाइल्ड क्लास एक हार्ड कोडेड वैल्यू दे देती है हमेशा। कोई भी चाइल्ड क्लास एक हार्ड कोड वैल्यू देती है। तो भी वो एक अच्छी चाइल्ड क्लास नहीं है। यानी कि सब्स्टिट्यूट नहीं हो सकती। तो ये सब कुछ बेसिक रूल्स हैं जो आप देख के आइडेंटिफाई कर सकते हो कि कोई भी चाइल्ड क्लास क्या सब्सीटुटेबल है अपनी पेरेंट क्लास के। अगर आप ये सारे रूल्स याद रखोगे पक्का पक्का आप कभी गलती नहीं करोगे। चलो लेट्स मूव ऑन टू आवर न्यू डिजाइन प्रिंसिपल दैट इज इंटरफेस सेग्रगेशन प्रिंसिपल। आ जाओ स्क्रीन पे। तो अब अपने नए डिजाइन प्रिंसिपल की तरफ हम मूव कर रहे हैं जिसको हम बोलते हैं इंटरफेस सेग्रगेशन प्रिंसिपल। ठीक है? अब ये क्या कहता है? सबसे पहले इसकी डेफिनेशन देखते हैं। तो ये है आईएसपी की डेफिनेशन इंटरफेस एग्रीगेशन प्रिंसिपल कि मेनी क्लाइंट स्पेसिफिक इंटरफेस आर बेटर देन वन जनरल पर्पस इंटरफेस। नाम से ही समझ आ रहा है कि बहुत सारे क्लाइंट स्पेसिफिक इंटरफेस बनाना हमेशा बेटर है कि आप एक जनरल पर पर्पस इंटरफेस बना दो जिसमें सारे के सारे मेथड घुसेड़ दो। बेसिकली इससे क्या दिक्कत होती है? जब आप उस इंटरफेस के चाइल्ड बनाते हो तो बहुत सारे ऐसे चाइल्ड होते हैं जिनको वो सारे मेथड्स की जरूरत नहीं होती। पर फिर भी उन सबको वो सारे मेथड्स को ओवराइड करना पड़ता है। राइट? तो अभी हमने ये सारी प्रॉब्लम रिस्क ऑफ सब्स्टट्यूशन प्रिंसिपल में भी देखी थी। अब इसे एग्जांपल से समझते हैं। आपको इजीली समझ आ जाएगा। देखो बहुत सिंपल एग्जांपल है इसका। सपोज़ करो हमारे पास ना एक पेरेंट क्लास है। शेप। ठीक है? मैंने कहा एक शेप एक पेरेंट क्लास है। और हर शेप में मैंने पहले बोला कि भाई एरिया तो निकल ही जाता होगा। तो मैंने एरिया का एक मेथड रख लिया। ठीक है? अब मैंने इसकी कुछ चाइल्ड क्लासेस बनाता हूं। तो एक मैंने लेट्स से बना दिया अ स्क्वायर। तो ये एक चाइल्ड क्लास बन गई। ऐसे ही लेट्स से एक मैंने बना दिया रेक्टेंगल। ये भी एक शेप है। राइट? तो ये भी एक चाइल्ड क्लास बन गई। तो इसकी मल्टीपल चाइल्ड क्लास हो गई। ठीक है? और क्योंकि मल्टीपल ये सारी चाइल्ड क्लास है तो ये भी एरिया को ओवराइड करेंगी। एरिया को ओवराइड करेगी। राइट? अब क्या होता है कि मैं एक नई चाइल्ड क्लास इंट्रोड्यूस करता हूं जो कि एक टू डी ऑब्जेक्ट है जिसका नाम है लेट्स से क्यूब। ठीक है? तो मैं क्यूब को इंट्रोड्यूस करता हूं। अब क्यूब में भी अगेन एरिया का मेथड मुझे ओवराइड करना पड़ेगा। तो मैंने क्यूब में एरिया का मेथड सॉरी क्यूब में एरिया का मेथड ओवराइड कर दिया। हां। एरिया। ठीक है? पर क्यूब में सिर्फ एरिया नहीं होता। क्यूब में तो आप वॉल्यूम भी निकाल सकते हो। तो मुझे लगा हां बात तो सही है। अब मैं और भी धीरे-धीरे करके और 3D और 2D ऑब्जेक्ट्स को जब इंट्रोड्यूस करूंगा तो उसमें मैं वॉल्यूम भी निकाल सकता हूं। तो यहां पे वॉल्यूम का मेथड भी हो सकता है। पर अब अगर मैंने सिर्फ यहीं वॉल्यूम रखा तो मुझे तो हर टू डी ऑब्जेक्ट के लिए वॉल्यूम को डिफाइन करना पड़ेगा। तो इससे बेटर मैं एक काम करता हूं ना ये जो मेन मेरी जो शेप क्लास है, शेप इंटरफेस है, लेट्स से ये एब्स्ट्रैक्ट क्लास है। ठीक है? तो ये इंटरफ़ेस का काम कर रहा है पूरा। अब ये एब्स्ट्रैक्ट क्लास है तो इसमें कोई डेफिनेशन नहीं है। सिर्फ डिक्लेरेशन है। तो इसी में मैं वॉल्यूम भी डिफाइन कर देता हूं। डिक्लेअ कर देता हूं कि भाई वॉल्यूम भी सबको ओवराइट करना पड़ेगा क्योंकि हर शेप में वॉल्यूम होता है। बट एक्चुअली हर शेप में वॉल्यूम नहीं होता। स्क्वायर में और रेक्टेंगल में वॉल्यूम नहीं हो सकता। एक टू डी फिगर है। क्यूब हमारा 3D फिगर है। राइट? तो मुझे क्या करना पड़ेगा? जबरदस्ती क्योंकि यहां पे वॉल्यूम है। तो मुझे यहां पे भी वॉल्यूम का मेथड डालना पड़ेगा। और उसको डिक्लअ करते हुए लेट्स से मैं कह सकता हूं थ्रो अ इनवैलिड आर्गुमेंट। राइट? सेम तरीके से मुझे यहां पे भी वॉल्यूम का मेथड डालना पड़ेगा। और यहां पे भी उसको डालते हुए मैं कह सकता हूं इनवैलिड आर्गुमेंट। पर जब मैं यहां पे वॉल्यूम का मेथड डालूंगा यहां पे मैं उसको सिंपली एग्जीक्यूट कर सकता हूं। मैं सिंपली डिक्लेअर कर सकता हूं कि भ क्यूब का वॉल्यूम क्या होता है वो लिख दो। राइट? अब क्यों ऐसा किया मैंने? ठीक है? मैंने क्या गलती की बेसिकली? मैंने क्या किया? मैंने ये तो कह दिया कि क्यूब एक तरह का शेप है और क्यूब में वॉल्यूम होता है। तो मैंने शेप में भी वॉल्यूम डाल दिया। पर हर क्लास में वॉल्यूम नहीं होता। यहां पे जैसे कि स्क्वायर में रेक्टेंगल में वॉल्यूम की जरूरत थी ही नहीं। तो इंटरफेस एग्रीगेशन प्रिंसिपल यहां पे ये कह रहा था कि मेनी क्लाइंट स्पेसिफिक इंटरफेस आर बेटर देन वन जनरल पर्पस इंटरफेस। अब हमने एक जनरल पर्पस इंटरफेस शेप तो बना दिया जिसमें बहुत सारे मेथड्स हैं। बट सारे सब टाइप्स को हर मेथड चाहिए ही नहीं शेप क्लास का। राइट? तो यही उसकी दूसरी लाइन थी। क्लाइंट शुड नॉट बी फोर्स टू इंप्लीमेंट मेथड दैट दे डोंट नीड। जैसे कि यहां पे स्क्वायर और रेक्टेंगल को वॉल्यूम की जरूरत नहीं थी। पर तब भी इनको इसे एग्जीक्यूट करना पड़ा। एग्जीक्यूट से मेरा मतलब है इनको डिफाइन करना पड़ा। सिर्फ क्यूब को उसकी जरूरत थी। तो क्यूब को डिफाइन करने देते। हम क्या करते? दो अलग-अलग इंटरफेस बना लेते। एक 2D शेप का अलग बनाते, एक 3D शेप का अलग बनाते। और यही है इंटरफेस को सेग्रगेट करने का प्रिंसिपल। इंटरफेस सेग्रगेशन प्रिंसिपल। ठीक है? अब इसको हम ठीक कैसे करते? इसको हम ऐसे ठीक करते कि हम दो तरह की शेप बनाते। एक बनाते 2D शेप। और एक बनाते 3D शेप। ठीक है? 2D शेप में हमारे पास सिर्फ एरिया होता और 3D शेप में हमारे पास एरिया और वॉल्यूम दोनों होता और ये दोनों क्या होते? एब्स्ट्रैक्ट होते। दोनों एब्स्ट्रैक्ट क्लास होते। अब जो भी चाइल्ड होता इसके जैसे लेट्स सपोज़ स्क्वायर हो गया। वो चाइल्ड हो जाता 2D शेप का। अगेन सेम रेक्टेंगल हो गया। वो भी चाइल्ड हो जाता 2D शेप का। ऑन दी अदर हैंड अगर अ 3D शेप का जो चाइल्ड की बात करें तो हमारा हो जाता क्यूब। राइट? तो अब क्या किया? हमने इंटरफ़ेस को सेग्रगेट कर दिया। अब स्क्वायर और रेक्टेंगल को सिर्फ एरिया को डिफाइन करने की जरूरत है और क्यूब एरिया और वॉल्यूम दोनों को डिफाइन कर सकता है। तो इंटरफेस एग्रीगेट हो गए। तो किसी भी चाइल्ड क्लास को अब देखो कोई भी ऐसा मेथड यूज़ करने की जरूरत ही नहीं है। डिफाइन करने की जरूरत ही नहीं है जिसको वो यूज़ नहीं करता। जैसे टू डी शेप वॉल्यूम यूज़ नहीं करता तो हमने स्क्वायर और रेक्टेंगल में वॉल्यूम डाला ही नहीं। एज़ सिंपल एज़ दैट। बस यही है पूरा प्रिंसिपल। इसका कोड देखते हैं और ये प्रिंसिपल खत्म। तो देखो ये वो कोड है जहां पे हमने आईएसपी को वायलेट किया है। तो हमने वही किया जो हमने एग्जांपल लिया। हमने शेप क्लास की एक एब्स्ट्रैक्ट क्लास बनाई। एरिया और वॉल्यूम दोनों डाल दिए। तो स्क्वायर एक शेप को इन्हहेरिट करता है। रेक्टेंगल भी करता है और सेम क्यूब भी करता है। लेकिन स्क्वायर में सिर्फ एरिया आप डिक्लअर कर सकते हो साइड इंटू साइड। उसे तो वो ओवरराइड कर देगा। पर वॉल्यूम को वो ओवराइड नहीं कर पाएगा। तो लॉजिकल एरर थ्रो कर देगा। वॉल्यूम नॉट एप्लीकेबल। सेम रेक्टेंगल करेगा। एरिया को ओवराइड कर देगा। लेंथ लेंथ * विड्थ पर वॉल्यूम को ओवराइड नहीं कर पाएगा तो लॉजिकल एरर थ्रो कर देगा। और 3D शेप दोनों को ओवराइड कर देगा। एरिया को भी, वॉल्यूम को भी। कोई दिक्कत नहीं होगी। पर ये जो है क्लाइंट यहां पे अब आईएसपी को ब्रेक कर देगा। क्योंकि बहुत सारे जनरल पर्पस हमने बेसिकली एक जनरल पर्पस इंटरफेस बना दिया जिसमें बहुत सारे जो चाइल्ड क्लास हैं उनको हर मेथड को ओवराइड करना पड़ रहा है। अब इसका सॉल्यूशन क्या है? तो ये है इसका सॉल्यूशन। हमने क्या किया? अलग-अलग इंटरफेस बनाए। एक टू डायमेंशनल शेप, एक थ्री डायमेंशनल शेप। टू डायमेंशनल में हमने सिर्फ एरिया डाला। थ्री में एरिया और वॉल्यूम दोनों डाला और सेम किया स्क्वायर 2D से 2D शेप से इन्हहेरिट करता है। रेक्टेंगल भी 2D से करता है और क्यूब 3D से करता है। अब क्यूब एरिया और वॉल्यूम दोनों को ओवराइड कर सकता है। रेक्टेंगल सिर्फ एरिया और स्क्वायर सिर्फ एरिया को ओवराइड करेगा क्योंकि अब इसे वॉल्यूम की जरूरत ही नहीं है। राइट? सो दैट्स इट। यही है इंटरफेस एग्रीगेशन प्रिंसिपल। आई होप ये सबसे सिंपल प्रिंसिपल होगा। राइट? अब फटाफट से मूव करते हैं अपने लास्ट प्रिंसिपल की तरफ जो है डिपेंडेंसी इन्वर्जन प्रिंसिपल। तो चलो अब अपना लास्ट प्रिंसिपल देखते हैं। व्हिच इज़ डिपेंडेंसी इन्वर्जन प्रिंसिपल। सबसे पहले अगेन इसकी डेफिनेशन। तो, यह है इसकी डेफिनेशन और यह कहती है कि हाई लेवल मॉड्यूल शुड नॉट डिपेंड ऑन लो लेवल मॉड्यूल बट रादर बोथ शुड डिपेंड ऑन एब्स्ट्रैक्शन। डेफिनेशन काफी वेग है। राइट? बट कहती बहुत सिंपल चीज है। देखो ये कहती है कि हमारे पास कुछ हाई लेवल मॉड्यूल्स हैं। कुछ लो लेवल मॉड्यूल हैं। राइट? ये दोनों सीधा इंटरेक्ट ना करें कभी भी। बल्कि इनके बीच में एक एब्स्ट्रैक्शन की लेयर होनी चाहिए। एब्स्ट्रैक्शन की लेयर मतलब एक इंटरफ़ेस होना चाहिए या फिर एक एब्स्ट्रैक्ट क्लास होनी चाहिए जिसके थ्रू ये इंटरेक्ट करें। तो कभी भी जो हाई लेवल मॉड्यूल है वो डायरेक्टली लो लेवल से बात ना करें। लो लेवल कभी भी डायरेक्टली हाई लेवल से बात ना करें। बल्कि एक कॉन्ट्रैक्ट के थ्रू बात करें। एक इंटरफेस के थ्रू बात करें। और ये अभी तक आप हमेशा फॉलो करके आए थे। ये सारे जो डिज़ाइन प्रिंसिपल्स हैं ना ये आपस में बहुत ज्यादा इंटरवाइंड है। आप एक को पढ़ते हो तो आपको याद आता है हां ये तो मैंने दूसरे पे भी अप्लाई किया था। सेम चीज इसके लिए है। तो इसका एक एग्जांपल देखते हैं। आपको बहुत ज्यादा बेटर समझ आएगा। ठीक है? इसको ऐसे देखो। सपोज़ करो आप एक एप्लीकेशन बनाते हो। ठीक है? तो आपके पास एक एप्लीकेशन है। मोबाइल एप्लीकेशन कह लो, सॉफ्टवेयर एप्लीकेशन कह लो, कुछ भी एक एप्लीकेशन बनाते हो जो क्या करती है? डेटाबेस से इंटैक्ट करती है सीधा। ठीक है? अभी डेटाबेस सीक्वल हो सकता है। राइट? मोंगो हो सकता है। कोई भी डेटाबेस हो सकता है। ठीक है? तो इस केस में ये जो आपकी एप्लीकेशन है, ये हो जाता है आपका हाई लेवल मॉड्यूल। हाई लेवल वो हर मॉड्यूल को कहते हैं जो आपके बिजनेस लॉजिक से डील करता है। राइट? और लो लेवल हो जाता है ये डेटाबेस लेयर। इसे हम कहते हैं लो लेवल मॉड्यूल। तो लो लेवल हर वो मॉड्यूल होता है जो सीधा सिस्टम से इंटैक्ट करता है। जैसे किसी डेटाबेस से इंटैक्ट करना, फाइल सिस्टम से इंटैक्ट करना, किसी एक्सटर्नल एपीआई कॉल करना वो सब लो लेवल मॉड्यूल है। हाई लेवल मतलब बिनेस लॉजिक से डील करना। तो मैं कह रहा था कि कोई भी हाई लेवल मॉड्यूल किसी भी लो लेवल मॉड्यूल से डायरेक्ट इंटरेक्ट ना करें। राइट? बल्कि हम क्या करें? उनके बीच में एक इंटरफ़ेस की लेयर को इंट्रोड्यूस कर दें। एप्लीकेशन इससे बात करें और ये फिर सीक्वल से बात करें। सेम सीक्वल इससे बात करें और ये फिर एप्लीकेशन से बात करें। ये सिंपल चीज मैं कह रहा था। अगर अभी भी समझ नहीं आया तो अब जब हम एग्जांपल देखेंगे उससे तो बिल्कुल समझ आ जाएगा। ठीक है? तो इसी एग्जांपल को थोड़ा सा एक्सपेंड करते हैं। तो मैं ये कह रहा था कि सपोज़ हमारे पास एक एप्लीकेशन है। तो ये हमारे पास एक क्लास हो जाती है। ठीक है? अब मुझे क्या करना है ना? इस एप्लीकेशन में मैंने कहा था डेटा से इंटरेक्ट करना है। डेटाबेस से इंटैक्ट करना है। तो डेटाबेस से इंटरेक्ट करने के लिए ये हमारे पास डेटाबेस है। ठीक है? इसको मैं अलग कलर से ड्रॉ कर लेता हूं। लेट्स से ये हमारे पास डेटाबेस है यहां पे। ये ठीक है? ये डीबी है। अब इससे इंटरेक्ट करने के लिए भी हमारे को कुछ क्लासेस चाहिए होंगी। राइट? डायरेक्टली थोड़ी इंटैक्ट करेंगे। तो मैंने क्या कहा? मैं दो क्लासेस और बना लेता हूं। एक अह एक का नाम है मोंगो डीबी जो मोंगो डेटाबेस इंटैक्ट करेगी और एक है सीक्वल डीबी जो सीक्वल डेटाबेस से इंटैक्ट करेगी। ठीक है? तो मैं दोनों के अलग-अलग डेटाबेस बना लेता हूं। लेट्स से ये इंटरेक्ट करती है एक सीक्वल डीबी से और ये इंटैक्ट करती है एक मोंगो डीबी से। तो इसको हटा लेते हैं। ठीक है? मोंगो डीबी से। ठीक है? तो मैंने दो अलग-अलग क्लासेस बना ली। मोंगो डीबी भी मंगो से इंटरेक्ट करती है। सीक्वल डीबी सीक्वल से इंटरेक्ट करती है। ये क्लासेस हैं। ठीक है? अब ये जो एप्लीकेशन है ये जो मैंने एप्लीकेशन बनाई है इसका काम है किसी भी डेटा को कोई भी जो डेटा मेरे पास आ रहा होगा लेट्स से यूजर का डेटा कोई भी रैंडम डेटा मुझे वो डेटा इन दोनों मोंगो डीबी और सीक्वल डीबी में सेव करना है। तो मेरे पास एक फंक्शन होगा लेट्स सेव टू डीबी। ऐसा कुछ फंक्शन होगा मेरे पास। तो इस फंक्शन को एक बार ध्यान से लिख लेते हैं। तो हमारे पास फंक्शन होगा सेव टू डीबी। पर मेरे को तो दोनों में सेव करना है। मोंगो में भी, सीक्वल में भी। तो मैं एक फंक्शन नहीं रख के मैं क्या करता हूं? मैं एक काम करता हूं। मैं इन दोनों का एक रेफरेंस रख लेता हूं। यानी कि हैज़ अ रिलेशनशिप रख लेता हूं। तो इसका मतलब क्या हुआ? मेरे पास एक तो अ सीक्वल डीबी का एक ऑब्जेक्ट है। लेट्स से एसडी इसको बोल देता हूं मैं। और एक हमारे पास मोंगो डीबी का एक ऑब्जेक्ट है। एमडी से बोल देता हूं मैं। ठीक है? तो ये मैंने हैज़ अ रिलेशनशिप हो गया। तो एप्लीकेशन के हैज़ अ मोंगो डीबी। एप्लीकेशन हैज़ अ सीक्वल डीबी। ठीक है? अब इसी एप्लीकेशन में इसको ये बहुत छोटा बन गया। तो मैं इसके कुछ मेथड्स यहां लिख रहा हूं। ठीक है? इसी एप्लीकेशन में कुछ मेथड्स हैं। तो एक होगा अ सेव टू सीक्वल। उस मेथड में क्या होता होगा? ये जो सीक्वल डीबी का ऑब्जेक्ट है एसडी ये एसडी पे कॉल करता होगा। सीक्वल में एक मेथड होगा लेट्स सेव। तो एसडी डॉट सेव राइट ऐसे ही एक और मेथड होगा सेव टू मोंगो डीबी। है ना? और वो क्या करता होगा? ये जो मोंगो का ऑब्जेक्ट है एमडी एमडी पे सेव कॉल करता होगा। राइट? इस पे भी एक सेव मेथड होगा। तो यही सब करता होगा। राइट? अब दिक्कत क्या हो रही है? देखो दिक्कत ये है कि जो ये है ना ये एक हाई लेवल मॉड्यूल है और ये दोनों एक लो लेवल मॉड्यूल है क्योंकि ये डेटाबेस से इंटैक्ट कर रहे हैं। अब इसमें ये जो हाई लेवल मॉड्यूल है ना ये डायरेक्टली लो लेवल मॉड्यूल से इंटरेक्ट कर रहा है। अब इसकी दिक्कत ये है कि लेट्स से कल को मुझे मोंगो डेटाबेस हटाना है और इसकी जगह मुझे कasandra डीबी यूज़ करना है। व्हिच इज़ अनदर टाइप ऑफ़ डीबी। ठीक है? तो मुझे क्या करना पड़ेगा? मुझे एक तो इस एप्लीकेशन क्लास को खोल के ये चेंज करना पड़ेगा कि यहां पे मोंगो डीबी का ऑब्जेक्ट हटेगा। यहां पे कasand डीबी का ऑब्जेक्ट आएगा और फिर मुझे उसका एक नया मेथड बनाना पड़ेगा। यानी कि मेरे को ओपन क्लोज प्रिंसिपल को ब्रेक करना पड़ेगा। राइट? तो इस प्रिंसिपल को ब्रेक ना कर पाऊं। मुझे क्या उसके लिए क्या करना चाहिए? मुझे डिपेंडेंसी इन्वर्जन कर देनी चाहिए। बेसिकली क्या करना चाहिए? एक इंटरफेस को इंट्रोड्यूस करना चाहिए बीच में। इन दोनों के बीच में जो कि मोंगो डीबी और सीक्वल डीबी से बात करें और एप्लीकेशन डायरेक्टली उस इंटरफेस से बात करे। तो इस प्रॉब्लम को सॉल्व करने के लिए हम क्या करते हैं? हम एक नया इंटरफेस इंट्रोड्यूस करते हैं। एक नई क्लास इंट्रोड्यूस करते हैं। अब आप ध्यान से सोचना हमने ये लास्ट किस में किया था। ठीक है? तो हम एक क्लास इंट्रोड्यूस करते हैं। अ एक काम करते हैं। सबसे पहले इसको रिमूव कर देते हैं सबको। तो अब एक बार हमने सब कुछ रिमूव कर दिया। अब हम क्या करते हैं? हम एक नई क्लास इंट्रोड्यूस करते हैं। जिनका जिसका नाम होगा पर्सिस्टेंस क्लास। ठीक है? अब एप्लीकेशन पहले सीक्वल और मोंगो दोनों से इंटरेक्ट कर रही थी। हैज़ अ रिलेशनशिप से। लेकिन अब एप्लीकेशन सिर्फ पर्सिस्टेंस क्लास से इंटैक्ट करेगी। यानी कि एप्लीकेशन हैज़ एन ऑब्जेक्ट ऑफ़ पर्सिस्टेंस क्लास P। ठीक है? और अब पर्सिस्टेंस क्लास से इन्हहेरिट करेंगे वो दोनों सब क्लास। कौन दोनों सब क्लास? सीक्वल DB और मोंगो डीबी और पर्सिस्टेंस क्लास में लेट्स से एक ही मेथड रखेंगे हम सेव और यह दोनों सेव को ओवराइड कर लेंगे अपने-अपने तरीके से। ये सेव को ओवराइड करेगी सीक्वल में सेव करने के लिए ये सेव को ओवर करेगी ये मोंगो से मोंगो में सेव करने के लिए। तो सेम ये सीक्वल से कनेक्टेड होगा और ये मोंगो से कनेक्टेड होगा। अब दिक अब फायदा हमारा इससे ये हुआ कि अब जो हमारा जो हाई लेवल मॉड्यूल था ना एप्लीकेशन उसमें ये दोनों फंक्शन होने की अब कोई जरूरत ही नहीं है। तो अगर हम इस फंक्शनंस को पूरे हटा दें तो अब दिस इज हाउ आवर एप्लीकेशन लुक्स। अब हमारे एप्लीकेशन में बस एक फंक्शन होना चाहिए जो कि इस P पे होगा P डॉट सेव। अब ये बस P का सेव कॉल कर देगा। अब पर्सिस्टेंस क्लास के ऊपर है कि वो सीक्वल में सेव करना चाहता है या मोंगो में सेव करना चाहता है। कैसे? जब भी हम इस पी के ऑब्जेक्ट को रेफर करेंगे। हो सकता है हम कंस्ट्रक्टर में P को पास कर रहे हो और इसको असाइन कर रहे हो। राइट? तो अब हो सकता है हम सीक्वल का इसको पास कर दें। हो सकता है हम मोंगो का इसको पास कर दें। जिसका भी हम डायनेमिकली एलोकेट करेंगे पॉलीमॉर्फिज्म के थ्रू इस पी को P डॉट सेव उसका कॉल हो जाएगा। ठीक है? तो अब एप्लीकेशन का मतलब नहीं है किसका सेव कॉल हो रहा है। एप्लीकेशन का मतलब है बस मुझे सेव कॉल करना है। तो हमने ये जो इंटरफ़ेस बीच में यूज़ किया ये एक्ट करता है एज अ एब्स्ट्रैक्शन बिटवीन अ हाई लेवल मॉड्यूल एंड बिटवीन दोज़ टू लो लेवल मॉड्यूल्स। ठीक है? बस इतना सा काम था। अब कल को अगर मेरे सीक्वल डीबी की जगह या मोंगो डीबी की जगह कसांड्रा डीबी भी चेंज कर दिया तो मैंने क्या किया होगा? मैंने एक नया बना दिया होगा कasandra डीबी इधर उसमें भी सेव मेथड होगा और रन टाइम पे मैं एप्लीकेशन के पी में कasra डीबी का ऑब्जेक्ट पास कर दूंगा पर मुझे एप्लीकेशन को क्या फर्क पड़ा एप्लीकेशन तो उसका भी सेव मेथड कॉल कर देगा सिंपली तो यही है डिपेंडेंसी इन्वर्जन प्रिंसिपल पूरा का पूरा अब इसे फटाफट इसका कोड देखते हैं तो सबसे पहले हमारा ये वो कोड है जहां पे हमारा डी डीआईपी बेसिकली डिपेंडेंसी इन्वर्जन प्रिंसिपल वायलेट हो रहा था तो देखो हमने क्या किया था एक माय सीक्वल का डेटाबेस बनाया मोंगो सीक्वल का डेटाबेस बनाया दोनों में सेव टू सीक्वल सेव टू मोंगो करके एक मेथड है। तो सेव टू सीक्वल क्या करता है? एक एग्जीक्यूट करता है एक एसक्यूएल क्वरी और डेटा को एसक्यूएल में सेव कर देता है। और वैसे ही सेव टू मोंगो क्या करता है? कुछ मोंगो डीबी फंक्शनं एग्जीक्यूट करता है और उसको मोंगो में सेव कर देता है। अब हम क्या करते हैं? एक यूजर सर्विस बनाते हैं। राइट? जहां पे हमने एग्जांपल में एप्लीकेशन लिया था। वहां पे हमने एक यूजर सर्विस लिया है। तो हम क्या करते हैं? मोंगो डीबी और सीक्वल डीबी के दोनों के एक रेफरेंस रख लेते हैं। यानी कि हैज़ अ रिलेशनशिप। अब हम क्या करते हैं? अगेन दो मेथड बनाते हैं। एक स्टोर यूजर टू सीक्वल, स्टोर यूजर टू मोंगो। अब यूजर सर्विस है तो ऑब्वियसली किसी यूजर को सेव कर रहा होगा। तो वो क्या करता है? एक यूजर पास करते हैं मतलब स्ट्रिंग और अ क्या करता है? मोंगो में भी सेव करते हैं और सीक्वल में भी स्टोर करते हैं। तो सीक्वल में स्टोर करने के लिए हम क्या करते हैं? जो सीक्वल डीबी का ऑब्जेक्ट है उस पे सेव टू सीक्वल कॉल करा देते हैं यूजर को पास करके। राइट? और वही मोंगो के साथ करते हैं। मोंगो डीबी के ऑब्जेक्ट में सेव टू मोंगो कॉल करा देते हैं यूजर को पास करके। तो हमें दो मेथड लिखने पड़े। यानी कि ये टाइटली कपल हो गया हाई लेवल हमारे इस लो लेवल मॉड्यूल से। ये टाइटली कपल हो गया। अब कल को अगर हम मोंगो डीबी को चेंज करके कasandra डीबी यूज़ करें तो हमें यूजर सर्विस के अंदर जाकर के स्टोर यूजर टू मोंगो फंक्शन को चेंज करना पड़ेगा। इसको चेंज करना पड़ेगा रेफरेंस को यानी कि ओपन क्लोज प्रिंसिपल पूरा का पूरा ब्रेक हो जाएगा। शटर हो जाएगा। तो इसको अवॉइड करने के लिए हमने यूज़ किया इसका सॉल्यूशन व्हिच इज़ डिप डिपेंडेंसी इन्वर्जन प्रिंसिपल। तो उसका कोड है ये। तो ये है डिपेंडेंसी इनवर्ज़ प्रिंसिपल को लगा के हमने क्या किया? देखो हमने जैसे पर्सिस्टेंस क्लास बनाई थी। यहां पे हमने डेटाबेस क्लास बनाई जिस पे सिर्फ एक वर्चुअल मेथड है सेव। तो ये एक एब्स्ट्रैक्ट क्लास है। इंटरफ़ेस है। बेसिकली एक एब्स्ट्रैक्शन का काम कर रहा है। ठीक है? ये प्योर वर्चुअल फंक्शन है। अब जो माय सीक्वल डेटाबेस और मोंग डीबी डे डेटाबेस है जो दोनों अलग-अलग क्लासेस थी। अब हमने उसको सब क्लास बना दिया डेटाबेस का। ठीक है? तो फिर दोनों ने सेव फंक्शन को ओवराइड किया और अपने-अपने तरीके से एग्जीक्यूट किया। तो ये एक्सक्यूएल क्वरी में सेव कर रहा है और ये मंगो डीबी में फंक्शन से सेव कर रहा है। ठीक है? अब देखो यूजर सर्विस के पास सिर्फ इस डेटाबेस का ऑब्जेक्ट है डीबी। यानी कि डिपेंडेंसी इंजेक्शन यूज़ किया हमने। डिपेंडेंसी इंजेक्शन कुछ नहीं होता। जब भी आप एक ऑब्जेक्ट पास करते हो ऐज़ अ वेरिएबल किसी भी अह क्लास के अंदर उसको हम डिपेंडेंसी इंजेक्शन कहते हैं। मतलब यहां पे हमने इस डिपेंडेंसी को इंजेक्ट कर दिया। ठीक है? इसको बाद में कभी अलग टर्म्स में पढ़ेंगे किसी अलग वीडियो में। तो हमने बेसिकली इस डीबी को यहां पे पास कर दिया। ठीक है? कंस्ट्रक्टर में हमने इस डीबी को ले लिया। अब ये डेटाबेस कोई भी तरह का हो सकता है। लेट्स से पॉलीमॉर्फिज्म की वजह से कभी माय सीक्वल आ सकता है, कभी मोंगो आ सकता है। हमें नहीं पता। कंस्ट्रक्टर में जो भी डेटाबेस आएगा, हम अपने डीबी को उससे असाइन कर लेंगे। और हमारा बस एक काम है हमारे पास एक मेथड है स्टोर यूजर जो हम क्या करते हैं इस डीबी में जो भी टाइप ऑफ डेटाबेस आया होगा चाहे मंगो आया होगा या सीक्वल आया होगा हम उसमें सेव मेथड कॉल कर देते हैं यूजर पास करके हमारा काम खत्म अब कल को चाहे तुम माय सीक्वल बदल दो मोंगो बदल दो हमें नई क्लासेस लिखनी पड़ेगी पर हमें इस क्लास में कोई चेंज नहीं करना पड़ेगा ठीक है यानी कि ओपन क्लोज प्रिंसिपल आपका इंटैक्ट रहेगा राइट फिर ये हमने उसको यूज कर लिया सिंपल ठीक है चलो अब एक फैक्ट डिस्कस कर लेते हैं। देखो सबसे पहले ना अगर ओपन क्लोज प्रिंसिपल को फॉलो करना है तो डिपेंडेंसी इन्वर्जन प्रिंसिपल को फॉलो करना ही पड़ेगा। इसकी एक लाइन कहते हैं इफ ओपन क्लोज प्रिंसिपल इज दी टारगेट देन डिपेंडेंसी इन्वर्जन प्रिंसिपल इज दी सॉल्यूशन। ये याद रखना। ये याद रखोगे सारी प्रॉब्लम सॉल्व हो जाएंगी। ठीक है? इसके अलावा अगर डिपेंडेंसी इन्वर्जन प्रिंसिपल को एक रियल लाइफ सिनेरियो से समझना है ना तो ऐसे समझो कि कंपनी में एक सीईओ होता है जो एक हाई लेवल है। हाई लेवल पे काम करता है और बहुत सारे लेट्स से हमारी टीम के हिसाब से मान लो डेवलपर्स होते हैं। राइट? डेवलपर्स होते हैं, क्यूएएस होते हैं। राइट? तो जो कि लो लेवल है। काफी लो लेवल पे काम कर रहे होते हैं। अब ये जो सीईओ है ये डायरेक्टली डेवलपर से बात नहीं करेगा। राइट? इसके हम क्या करेंगे? बीच में एक इंटरफेस को इंट्रोड्यूस करेंगे। एब्स्ट्रैक्शन को इंट्रोड्यूस करेंगे जिसे मैनेजर बोलते हैं। अब जो सीईओ है वो मैनेजर से बात करेगा। अगर कोई भी काम करवाना है डेवलपर से। सेम वे में अगर डेवलपर को अपना कोई मैसेज सीईओ तक पहुंचाना है तो वो मैनेजर से इंटैक्ट करेगा। अब कल को अगर डेवलपर्स चेंज भी हो जाए तो सीईओ को वो पता होने की जरूरत नहीं है। सीईओ को ये नहीं पता होना चाहिए कौन डेवलपर्स आ रहे हैं, कौन जा रहे हैं। उसको बस ये पता है कि मुझे मैनेजर को बोलना है ये काम करवाने के लिए। बाकी मैनेजर संभाल लेगा। तो बिल्कुल सेम यहां पे हो रहा है कि ये जो डेटाबेस लेयर है हमेशा एप्लीकेशन जो ये यहां पे यूजर सर्विस है ये हमेशा डेटा उस डेटाबेस को बोलता है कि मुझे डेटा को सेव करना है। अब चाहे वो सीक्वल में करें मोंगो में करें डिपेंडिंग अपॉन कौन सा पास हुआ है डायनेमिकली पॉलीमॉर्फिज्म के थ्रू। राइट? तो दिस इज़ ऑल अबाउट डिपेंडेंसी इन्वर्जन प्रिंसिपल एंड दिस इज़ ऑल अबाउट सॉलिड डिज़ाइन प्रिंसिपल इन जनरल। अब एक लास्ट क्वेश्चन जो हो सकता है आप लोगों के माइंड में आया हो कि भैया आपने तो कहा था कि हम ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में ना रियल वर्ल्ड को मैप करते हैं। राइट? पर यहां पे तो देखो हमारे पास डिपेंडेंसी इन्वर्जन प्रिंसिपल है। सिंगल रिस्पांसिबिलिटी प्रिंसिपल है। हम कह रहे हैं कि एक क्लास की एक ही रिस्पांसिबिलिटी होनी चाहिए। यानी कि एक ऑब्जेक्ट की एक ही रिस्पांसिबिलिटी होनी चाहिए। पर रियल लाइफ में तो ऐसा नहीं होता। रियल लाइफ में तो ऑब्जेक्ट बहुत कॉम्प्लिकेटेड होते हैं। फॉर एग्जांपल यूजर है, एक इंसान है, ह्यूमन है वो तो अगर ह्यूमन एक ऑब्जेक्ट है, वो तो बहुत कुछ करता है रियल लाइफ में। वो खाना खाता है, वो सोता है, वो गाना गाता है, वो नहाता है, वो बहुत कुछ करता है। राइट? पर जब हम उसको प्रोग्रामिंग में एक्सप्लेन कर रहे थे तो हम उसे क्या कर रहे थे? हम कह रहे थे उसकी सिंगल रिस्पांसिबिलिटी होनी चाहिए। तो इसे आप कैसे समझाओगे? देखो इसे ऐसे समझो कि जैसे कि रियल लाइफ में जो कोई भी ऑब्जेक्ट होता है ना वो बहुत कॉम्प्लिकेटेड होता है। राइट? वो बहुत सारे बिहेवियर शो कर सकता है। पर हर ऑब्जेक्ट हर बिहेवियर हर सिनेरियो में शो नहीं करता। तो बेसिकली इसका मतलब ये है कि अगर एक ह्यूमन है ना अगर सिनेरियोस बदल दो तो वो अलग-अलग बिहेवियर शो करेगा। फॉर एग्जांपल अगर वो ह्यूमन किसी ऑफिस में है तो वो अ काम करने का सिनेरियो काम करने का बिहेवियर शो करेगा। पर सोने का बिहेवियर शो नहीं करेगा। वहां पे स्लीप फंक्शन को कॉल नहीं करेगा अपने। राइट? सेम वे में अगर वो घर पे है तो वो स्लीप कॉल करेगा। पर वो हो सकता है काम ना करे। राइट? तो सिनेरियो डिफरेंट हुआ। इसी तरीके से उसने काम अपने अलग-अलग बिहेवियर को कॉल करना शुरू कर दिया। प्रोग्रामिंग भी बस वही है। जब हम एक रियल लाइफ ऑब्जेक्ट को प्रोग्राम में डिनोट करते हैं ना तो हम बस कहते हैं ये जो अलग-अलग सिनेरियो थे ना इसी को हम एप्लीकेशनेशंस बोल देते हैं। तो हम कहते हैं एक रियल लाइफ ऑब्जेक्ट जैसे कि ह्यूमन जिसको हम यूजर भी बोल सकते हैं। वो अलग-अलग एप्लीकेशन में अपने अलग-अलग बिहेवियर को ही कॉल करेगा। फॉर एग्जांपल अगर एप्लीकेशन है Ola Uber तो वो जो यूजर ऑब्जेक्ट है ना वो राइड बुक कर सकता है। राइट? वो राइड पे जा सकता है। वो राइड कैंसिल कर सकता है। लेकिन अगर एप्लीकेशन बदल दी जाए एप्लीकेशन को हम स्विगी Zomato कर दें तो अब यूजर की रिस्पांसिबिलिटीज़ बदल जाएंगी। यूजर की फंक्शनैलिटीज़ बदल जाएंगी। बेसिकली यूजर कर तो सब कुछ सकता है लेकिन वन टाइम पे एक ही एप्लीकेशन में वो सिर्फ अपने कुछ ही बिहेवियर को शो कर रहा है। तो SWGI Zomato पे वो क्या करेगा? वो खाना ऑर्डर कर सकता है। वो यहां पे कोई राइड कैंसिल नहीं कर सकता। पर वो यहां पे खाना कैंसिल कर सकता है। आप फर्क समझ रहे हो? तो बस इसको इस तरह दिमाग में रखो कि हम हमेशा रियल लाइफ ऑब्जेक्ट को ही मैप कर रहे होते हैं प्रोग्रामिंग में। पर जैसे रियल लाइफ में हर ऑब्जेक्ट अलग-अलग सिनेरियो में अलग-अलग बिहेवियर शो करता है ना वैसे ही प्रोग्रामिंग में भी हम यही बात करते हैं कि अलग-अलग एप्लीकेशन में हम यूजर के अलग-अलग मेथड शो करेंगे। राइट? तो यूजर ऑब्वियसली बहुत कॉम्प्लिकेटेड ऑब्जेक्ट है। हर ऑब्जेक्ट कॉम्प्लिकेटेड हो सकता है। पर हमें हमें बस उसकी सिर्फ वो फंक्शनैलिटी चाहिए जिसका हमें उस एप्लीकेशन से लेना देना है। तो इससे आप उसे बेटर समझ सकते हो। और एक लास्ट बात मैं कहूंगा कि जितने भी आपने सॉलिड डिजाइन प्रिंसिपल्स पढ़े हैं ना इनको हम प्रिंसिपल्स कहते हैं ना कि लॉ। इसका मतलब ये है कि ये ना बहुत आइडियल चीजें हैं। आपको देखा ही होगा आपने कि बहुत सारी एप्लीकेशनेशंस इन्हें एज इट इज़ फॉलो कभी नहीं कर सकती। बहुत मुश्किल है करना। अगर आप एक ऐसा कोड लिखो जो सारे सॉलिड डिज़ाइन प्रिंसिपल्स को फॉलो कर रहा हो। ये बहुत ही अमेजिंग बात है और बहुत ही आइडियल चीज़ है। राइट? कभी ना कभी आप एक ऐसे अ टर्म पे आ जाते हो जहां बिजनेस लॉजिक संभालने के लिए आपको सॉलिड डिजाइन प्रिंसिपल को थोड़ा बहुत ब्रेक करना पड़ता है। तो ये हमेशा ना एक ट्रेड ऑफ होता है। राइट? जैसे आप डीएसए में ट्रेड ऑफ की बात करते हो टाइम कॉम्प्लेक्सिटी और स्पेस कॉम्प्लेक्सिटी के बीच कि हमेशा टाइम बचाने के लिए आप ज्यादा स्पेस नहीं ले सकते। राइट? हमेशा आप हैश मैप यूज़ नहीं कर सकते। जस्ट बिकॉज़ आपका टाइम बच जाएगा। कहीं ना कहीं स्पेस भी एक रिक्वायरमेंट होती है। वैसे यहां पे एक ट्रेड ऑफ होता है कि कब आपको सॉलिड डिज़ाइन प्रिंसिपल को थोड़ा सा ब्रेक करना है अपने बिज़नेस लॉजिक को संभालने के लिए। क्योंकि एट द एंड ऑफ द डे बिज़नेस लॉजिक ही तो मेन है। वही तो पैसा ला के दे रहा है किसी एप्लीकेशन को। राइट? तो कभी कबभार हमें ट्रेड ऑफ हमेशा मेंटेन करना पड़ता है। तो ये बात हमेशा याद रखना ये डिज़ प्रिंसिपल्स कोई लॉ नहीं है। ये प्रिंसिपल्स हैं। इसलिए थोड़ा बहुत 1920 इसमें चल सकती है। पर स्टिल हमें कोशिश करनी चाहिए जितना ज्यादा इसे फॉलो कर पाएं उतना अच्छा है। उतना हमारा कोड क्लीनर बनेगा। उतना हमारा कोड एक्सपेंडेबल होगा और उतना हमारा कोड स्केलेबल होगा। राइट? तो इस वीडियो में बस इतना ही। अब से मिलते हैं नेक्स्ट वीडियो में। तब तक के लिए थैंक यू सो मच। तो