वस्तु-उन्मुख अवधारणाओं और प्रोग्रामिंग को सिखाने के लिए कुछ वास्तविक व्यावहारिक उदाहरण (पायथन में)

Question

मैंने अपने हाई स्कूल के छात्रों को कुछ सरल पायथन स्क्रिप्ट लिखना सिखाया है , "पायथन के साथ बोरिंग सामग्री को स्वचालित करें" से कुछ विचार लेते हुए , उदाहरण के लिए किसी फ़ोल्डर में फ़ाइल नामों को एक विशिष्ट नामकरण पैटर्न में बदलना।

मेरा अगला लक्ष्य उन्हें वस्तु-उन्मुख अवधारणाओं को सिखाना है और यदि संभव हो तो उन्हें खुद को आजमाने के लिए कुछ "वास्तविक" उदाहरण दें। लेकिन ओओ प्रोग्रामिंग (सिर्फ अजगर नहीं) के बारे में मुझे मिलने वाली अधिकांश सामग्री (गूगल के अधिकांश शीर्ष खोज परिणाम) खराब उदाहरणों से भरी हुई हैं, अगर मैं ऐसा कह सकता हूं। मैं वास्तव में उन्हें ओओ अवधारणा और ओओपी सिखाने के लिए कार/वाहन या पशु/कुत्ते का उपयोग करना पसंद नहीं करता।

A. यह उबाऊ है (आप हाई स्कूल के बच्चों को जानते हैं)
B. इसका कोई वास्तविक उपयोग नहीं है।
सी। जैसा कि एक टिप्पणी ने कहा "वे मोटे तौर पर त्रुटिपूर्ण हैं।" (लेकिन यदि आप वास्तव में पशु उदाहरण का उपयोग करना पसंद करते हैं, तो इस "ऑब्जेक्ट-ओरिएंटेड डिज़ाइन" को देखें )

मैं पथलिब का उपयोग करने की योजना बना रहा हूं ( बीटीडब्ल्यू , उनके पास पहले से ही विंडोज़ और यूनिक्स के बीच अंतर का मूल विचार है)

ओओपी सिखाने के लिए जीयूआई विकास एक और अच्छा उदाहरण हो सकता है लेकिन मैं अभी तक उन्हें जीयूआई नहीं सिखाना चाहता हूं।

ओओ को "असली" उदाहरण के साथ पेश करने का कोई सुझाव?

BTW, मैं ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का प्रबल समर्थक नहीं हूं। लेकिन pathlib.Pathकक्षा विशेष रूप से os.path की तुलना में एक उपयोगी अमूर्तता है, हालांकि हाई स्कूल के छात्रों को इसकी सराहना करने की संभावना नहीं है।

---- अपडेट करें ----

मुझे लगता है कि पायथन लॉगिंग मॉड्यूल एक और अच्छा उदाहरण है, लेकिन यह गैर-अनुभवी प्रोग्रामर के लिए बहुत जटिल लगता है।

लॉगिंग मॉड्यूल का उपयोग करते समय हम मुख्य रूप से 3 ऑब्जेक्ट्स, लॉगर, हैंडलर, फॉर्मेटर का उपयोग करते हैं । लकड़हारा मुखौटा है , जैसाhttps://docs.python.org/3/howto/logging.html#loggers कहा हुआ,

लॉगर ऑब्जेक्ट्स में तीन गुना काम होता है। सबसे पहले, वे एप्लिकेशन कोड के लिए कई तरीकों का खुलासा करते हैं ताकि एप्लिकेशन रनटाइम पर संदेशों को लॉग कर सकें। दूसरा, लॉगर ऑब्जेक्ट यह निर्धारित करते हैं कि गंभीरता (डिफ़ॉल्ट फ़िल्टरिंग सुविधा) या फ़िल्टर ऑब्जेक्ट के आधार पर कौन से लॉग संदेशों पर कार्य करना है। तीसरा, लकड़हारा ऑब्जेक्ट प्रासंगिक लॉग संदेशों के साथ सभी इच्छुक लॉग हैंडलर को पास करते हैं।

विरासत का उपयोग करने के लिए हैंडलर एक अच्छा उदाहरण है https://docs.python.org/3/howto/logging.html#useful-handlers और हैंडलर फ़ॉर्मेटर का उपयोग करते हैं, जो लॉग संदेश को प्रारूपित करने के लिए LogRecord की जटिलता को छिपाते हैं।

इन वर्गों के अलावा, सुविधाजनक उपयोग के लिए कई मॉड्यूल-स्तरीय कार्य हैं।

कुल मिलाकर यह रचना और एकत्रीकरण का उपयोग करने का एक अच्छा उदाहरण है ।

लेकिन मैं अजगर लॉगिंग मॉड्यूल का विशेषज्ञ नहीं हूं, मुझे आशा है कि कोई व्यक्ति जो अजगर लॉगिंग मॉड्यूल से परिचित है, वह मेरे प्रश्न का उत्तर जोड़ सकता है।

--- अपडेट 2 ----

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

एक "भाग" निर्माण जो इसके अंदर से बाहर से इसकी रक्षा कर सकता है, और इसके विपरीत

एक "संचार" निर्माण जो बातचीत को व्यक्त कर सकता है और निर्भरता से निपट सकता है

एक "सिस्टम" निर्माण जो भागों और संचारों का एक संयोजन है जो एक हिस्से में पुनरावर्ती रूप से फिट हो सकता है, और सब कुछ इस तरह से बनाया गया है

जो "संदेश" संप्रेषित किए जाते हैं, वे भी सिस्टम के संदर्भ में होते हैं

जो सिस्टम बनाया जा रहा है वो उसी तरह के सिस्टम से बना है...

Answer 1

मैं इसे कुछ बार अपडेट करने की उम्मीद करता हूं और अंत में एक लंबा जवाब होने की उम्मीद करता हूं।

लेकिन मैं कुछ ऐसी बातें समझाना शुरू करता हूं जिनके बारे में आप पहले से जानते होंगे, लेकिन अन्य पाठक शायद नहीं।

सबसे पहले, ओओ प्रोग्रामिंग मूल रूप से विरासत के बारे में नहीं है और बहुत सारी किताबें और लेखक इसे समझने में असफल होते हैं। इसके अलावा, वे विरासत का उपयोग भयानक तरीके से करते हैं जिससे सॉफ़्टवेयर को समझना कठिन हो जाता है और बनाए रखना कठिन हो जाता है।

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

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

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

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

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

दो सिद्धांत जो ध्यान में रखने योग्य हैं और लगभग हमेशा पालन करते हैं, लिस्कोव प्रतिस्थापन सिद्धांत और डेमेटर का कानून हैं ।

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

लिस्कोव सिद्धांत, निश्चित रूप से ठोस के तत्वों में से एक है जिसे आपको अपनी सोच में शामिल करने की भी आवश्यकता है।

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

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

डिज़ाइन पैटर्न ऐसे उपकरण हैं जिनकी आपको अधिकांश OO भाषाओं में एक प्रभावी प्रोग्रामर बनने की आवश्यकता है। रणनीति, डेकोरेटर, ऑब्जर्वर और इटरेटर विशेष रूप से सहायक हैं। इनमें से अधिकांश वास्तव में विभिन्न जावा पुस्तकालयों के निर्माण के लिए उपयोग किए जाते हैं।

---

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

कालकोठरी खेल

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

ध्यान दें कि क्लासिक बोर्ड गेम च्यूट्स (या सांप) और सीढ़ी इसका एक सरलीकृत संस्करण है। एक पाठ आधारित संस्करण बहुत जटिलता से बचा जाता है।

कैलकुलेटर

कैलकुलेटर में चाबियां और डिस्प्ले जैसे हिस्से होते हैं। आंतरिक मेमोरी कम दिखाई देती है, संभवतः एक स्टैक। यहां तक ​​​​कि संचालन भी वस्तुएं हो सकती हैं। गणना की स्थिति (रणनीति पैटर्न) के आधार पर चाबियों का व्यवहार बदलता है। वास्तव में एक IF स्टेटमेंट के बिना एक साधारण कैलकुलेटर बनाना संभव है।

एक असेंबली भाषा के साथ सार कंप्यूटर Ab

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

स्टिकी नोट्स (मैंने यह कोशिश नहीं की है)

एक ऐसा एप्लिकेशन जो उपयोगकर्ताओं को नोट्स और क्रॉस रेफरेंस रखने और उन्हें व्यवस्थित करने देता है। कुछ वर्ग नोट्स, कीवर्ड, कनेक्शन, सूचियां हो सकते हैं।

ख़तरा

टीवी से ख़तरनाक खेल के लिए एक सिम्युलेटर। श्रेणियाँ, उत्तर, प्रश्न, टीमें, स्कोर।

(जल्द ही वापस, शायद)।

Answer 2

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

ओओपी के लिए बहस करने का यह एक आसान तरीका है, कुछ "फ्लैट" ठोस मौजूदा कोड लेकर और अमूर्तता की तलाश में, जो डेटा को फ़ंक्शन पैरामीटर से कक्षा में ले जा सकता है, और उपयोग कर सकता है self।

विरासत जैसी चीजें भी लगभग स्वाभाविक रूप से ही खोजी जा सकती हैं; आप एक मौजूदा वर्ग का उपयोग करते हैं जो वह नहीं करता जो आप चाहते हैं और आपको इसे बदलने की जरूरत है; इसे कॉपी और संशोधित करने के बजाय, आप उप-वर्ग करते हैं और एक विधि बदलते हैं या जोड़ते हैं।

ठोस उदाहरणों के लिए, आप कंप्यूटर हार्डवेयर को ही देख सकते हैं। निम्न स्तर पर, रजिस्टरों को अक्सर कई अलग-अलग कार्यों में विभाजित किया जाता है। यदि आप एक फीचर बिट को 1 पर सेट करना चाहते हैं, तो आपको इसे 20 बिट्स के बाईं ओर शिफ्ट करना होगा, रजिस्टर का वर्तमान मूल्य पढ़ना होगा, बिट्स को 0 से 5 तक मास्क करना होगा क्योंकि वे "क्लियर करने के लिए 1 लिखें", और इसी तरह। सीरियल पोर्ट १६५५० यूआर्ट का अनुकरण करने का प्रयास करें; यह आत्मा के लिए अच्छा है। और, ज़ाहिर है, यदि आप वास्तविक माइक्रोप्रोसेसर पर चलने वाले माइक्रोपायथन का उपयोग करते हैं, तो आप शायद अपना कोड भी आज़मा सकते हैं।

Answer 3

डेटा मॉडलिंग और OOP (जो दोनों ही मामलों में एक तरह के सामान्यीकरण के इर्द-गिर्द घूमते हैं) दोनों के लिए मेरा गो-टू उदाहरण एक वीडियो रेंटल स्टोर है । यह शायद एक बहुत पुराना उदाहरण है, इसे पुस्तकालय या अन्य चीजों के लिए किराये की दुकान में बदलने के लिए स्वतंत्र महसूस करें, लेकिन मुझे लगता है कि वीडियो स्टोर उदाहरण दोनों ओओपी और डेटा सामान्यीकरण की पेचीदगियों को उजागर करते हैं, जबकि एक ही समय में एक बहुत ही सरल है समझने के लिए संदर्भ।

मुख्य लक्ष्य तीन टेबल/क्लास डायग्राम बनाना है: Customer, Videoऔर Rental(जो ग्राहकों और वीडियो के बीच क्रॉस टेबल है)।

इस उत्तर के बाकी हिस्सों में केवल उदाहरण के लिए विशिष्ट ओओपी मूल बातें कैसे संबंधित हैं, इस पर सुझाव हैं।

---

वस्तुएं क्यों?

ठीक है, आप अपने वीडियो डेटा को कैसे स्टोर करेंगे, यदि आप किराये के लिए तीन चीजों को ट्रैक करना चाहते हैं: ग्राहक का नाम, पता, वीडियो का नाम और वापसी की अपेक्षित तिथि।

छात्रों से एक बहुत ही सरल प्रोग्राम लिखने के लिए कहें जो आपको यह बताने में सक्षम हो कि ऐलिस ने एंट्ज़ किराए पर लिया, बॉब ने बी मूवी किराए पर ली, और चार्ली ने कार किराए पर ली। उन्हें कुछ पुन: प्रयोज्य PrintRentalInfoविधि पर भरोसा करने दें, लेकिन उन्हें विधि मापदंडों को परिभाषित करने की अनुमति दें जैसा कि वे फिट देखते हैं।

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

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

वास्तव में हाइलाइट करें कि यह कितना आसान है कि आप सभी प्रासंगिक जानकारी को एक साथ रखते हुए इस रेंटल "बैग" को एक विधि से दूसरे तरीके से स्थानांतरित कर सकते हैं।

---

एक से अधिक वर्ग क्यों?

चौथा ग्राहक दिखाई देता है। उसका नाम भी ऐलिस है। आप यहां एक समस्या में भाग लेते हैं, क्योंकि अब आप यह नहीं बता सकते हैं कि ऐलिस ने कौन से वीडियो किराए पर लिए हैं, और आप गलत ऐलिस को ठीक नहीं करना चाहते हैं।

साथ ही, मूल ऐलिस ने हमें यह बताने के लिए कॉल किया है कि उसका पता बदल गया है। सभी किराए के माध्यम से जाने और यह पता लगाने की कठिनाई को इंगित करें कि आप "old_address" को "new_address" में आँख बंद करके नहीं बदल सकते हैं, क्योंकि उसी पते पर रहने वाले अन्य ग्राहक भी हो सकते हैं जो ऐलिस के साथ नहीं गए थे। इसके अलावा, आप या तो नाम पर भरोसा नहीं कर सकते, क्योंकि चौथे ऐलिस ने पहले ही कुछ किराये भी बना लिए हैं।

यदि छात्र विरोध करते रहें कि आप इसे नाम और पते के संयोजन के आधार पर कर सकते हैं, तो क्या होगा यदि वे दो ऐलिस एक ही पते पर रहते हैं, और उनमें से केवल एक ही चलता है।

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

लक्ष्य: एक Customerवर्ग बनाएं, और बदलें Rentalताकि इसमें Customerनाम/पता गुणों के विपरीत एक संपत्ति शामिल हो ।

फोकस: बहुत अधिक हाइलाइट करें कि आप दो अलग-अलग ग्राहक ऑब्जेक्ट कैसे प्राप्त कर सकते हैं , भले ही उनके नाम और पते समान हों।

अतिरिक्त: आप Videoकक्षा बनाने के लिए वही तरीका अपना सकते हैं , ताकि आप अपने पास मौजूद विशिष्ट वीडियो को ट्रैक कर सकें। शायद इसे विद्यार्थियों के लिए एक अभ्यास के रूप में छोड़ दें, क्योंकि यह बहुत कुछ पहले जैसा ही है।

---

इस बिंदु से, आप जो दिखाना चाहते हैं उसके आधार पर आप व्यावसायिक तर्क का विस्तार कर सकते हैं।

• वंशानुक्रम - हो सकता है कि स्टोर किराए पर लेता है Videoऔर Game, लेकिन आप अभी भी Rentalउनमें से किसी एक से लिंक करने में सक्षम होना चाहते हैं (आधार RentableObjectवर्ग का उपयोग करके )
• इंटरफ़ेस - आप विरासत के समान उदाहरण का उपयोग कर सकते हैं।
• डेटा सामान्यीकरण - हमारे पास उपलब्ध फिल्मों और व्यक्तिगत भौतिक कैसेट (हमारे पास एक ही फिल्म के कई हो सकते हैं) को ट्रैक करने के बारे में हम कैसे जाएंगे? एक ग्राहक द्वारा किए गए जुर्माने को कैसे ट्रैक कर पाएंगे, और उनमें से किसका भुगतान उन्होंने पहले ही कर दिया है?
• डाटा परिवर्तन - हमारे मालिक किए गए सभी किराया पर एक साप्ताहिक रिपोर्ट मुद्रित करने के लिए हमें चाहता है, किराया लौटे, किए गए जुर्माना, और जुर्माना जो पहले से अभी भी भुगतान नहीं किया गया।
• संदर्भ बनाम मान - और Priceदोनों में a जोड़ें । दिखाएँ कि आपने किस तरह से पर आधारित सेट किया है , लेकिन जब बाद में परिवर्तन होता है, तो यह अछूता रहता है। अब उसी अभ्यास को एक संदर्भ वस्तु के साथ दोहराएं (उदाहरण के लिए ग्राहक का नाम बदलना)।VideoRentalrental.Pricevideo.Pricevideo.Pricerental.Price

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