OOP में शून्य व्यवहार ऑब्जेक्ट - मेरा डिज़ाइन दुविधा

Question

OOP के पीछे मूल विचार यह है कि डेटा और व्यवहार (उस डेटा पर) अविभाज्य हैं और वे एक वर्ग के ऑब्जेक्ट के विचार से युग्मित हैं। ऑब्जेक्ट में डेटा और विधियाँ हैं जो उस (और अन्य डेटा) के साथ काम करती हैं। ओओपी के सिद्धांतों द्वारा स्पष्ट रूप से, ऑब्जेक्ट जो केवल डेटा (जैसे सी संरचनाएं) हैं, उन्हें एक विरोधी पैटर्न माना जाता है।

अब तक सब ठीक है।

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

मैं आम तौर पर एक तरह से कक्षाओं को डिजाइन करता हूं जो अन्य वर्गों के अस्तित्व के बारे में उनकी जागरूकता को कम करता है और अन्य वर्गों के इंटरफेस के बारे में उनके ज्ञान को कम करता है। मैं इसे विशेष रूप से टॉप-डाउन फैशन में लागू करता हूं, निचले स्तर की कक्षाएं उच्च स्तर की कक्षाओं के बारे में नहीं जानती हैं। उदाहरण के लिए:

मान लीजिए कि आपके पास एक सामान्य कार्ड गेम एपीआई है। आपकी एक क्लास है Card। अब इस Cardवर्ग को खिलाड़ियों को दृश्यता निर्धारित करने की आवश्यकता है।

एक तरीका यह है boolean isVisible(Player p)पर Cardवर्ग।

एक और है boolean isVisible(Card c)पर Playerवर्ग।

मैं विशेष रूप से पहले दृष्टिकोण को नापसंद करता हूं क्योंकि यह उच्च स्तर की Playerकक्षा के बारे में निचले स्तर के Cardवर्ग के लिए ज्ञान देता है ।

इसके बजाय मैंने तीसरे विकल्प का विकल्प चुना जहां हमारे पास एक Viewportवर्ग है, Playerजो कार्ड की एक सूची देता है और निर्धारित करता है कि कौन से कार्ड दिखाई दे रहे हैं।

हालाँकि यह दृष्टिकोण एक संभावित सदस्य फ़ंक्शन के दोनों Cardऔर Playerवर्गों को लूटता है। एक बार जब आप ताश के पत्तों की दृश्यता के अलावा अन्य सामान के लिए ऐसा करते हैं, आप के साथ छोड़ दिया जाता है Cardऔर Playerवर्ग है जो विशुद्ध रूप से डेटा होते हैं के रूप में सभी कार्यक्षमता अन्य वर्गों, जो ज्यादातर कोई डेटा, बस तरह-तरह के साथ वर्ग हैं में कार्यान्वित किया जाता Viewportऊपर।

यह ओओपी के प्रमुख विचार के खिलाफ स्पष्ट रूप से है।

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

पुनश्च यहाँ एक और उदाहरण है:

मान लें कि आपके पास वह वर्ग है DocumentIdजो अपरिवर्तनीय है, केवल एक BigDecimal idसदस्य है और इस सदस्य के लिए एक गेट्टर है। अब आपको कहीं एक विधि की आवश्यकता है, जिसने एक डेटाबेस से इस आईडी के लिए DocumentIdरिटर्न दिया हो Document।

क्या आप:

• कक्षा में Document getDocument(SqlSession)विधि जोड़ें DocumentId, अचानक अपनी दृढ़ता ( "we're using a database and this query is used to retrieve document by id") के बारे में ज्ञान का परिचय देते हुए , डीबी और इसी तरह उपयोग किए जाने वाले एपीआई का उपयोग करें। इस वर्ग को भी अब संकलन करने के लिए दृढ़ता JAR फ़ाइल की आवश्यकता है।
• विधि के साथ कुछ अन्य वर्ग जोड़ें Document getDocument(DocumentId id), DocumentIdवर्ग को मृत के रूप में छोड़ दें , कोई व्यवहार नहीं, संरचना जैसा वर्ग।

Comments

यहां आपके कुछ परिसर पूरी तरह से गलत हैं, जो अंतर्निहित प्रश्न का उत्तर देना बहुत मुश्किल है। अपने प्रश्नों को संक्षिप्त और राय-रहित रखें जितना आप कर सकते हैं और आपको बेहतर उत्तर मिलेंगे।

— pdr

"यह स्पष्ट रूप से ओओपी के प्रमुख विचार के खिलाफ है" - नहीं, इसकी नहीं, बल्कि इसकी आम गिरावट है।

— डॉक ब्राउन

मुझे लगता है कि समस्या इस तथ्य में निहित है कि अतीत में "ऑब्जेक्ट ओरिएंटेशन" के लिए अलग-अलग स्कूल हैं - जिस तरह से मूल रूप से एलन के जैसे लोगों द्वारा इसका मतलब था (देखें geekswithblogs.net/theArchitectsNapkin-archive/2013/09/08/ … ), और जिस तरह से तर्कसंगत ( en.wikipedia.org/wiki/Object-oriented_analysis_and_design ) से उन लोगों द्वारा OOA / OOD के संदर्भ में पढ़ाया जाता है ।

— डॉक ब्राउन

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

— थियागो सिल्वा

कौन कहता है कि बेजुबान वर्ग एक प्रतिमान है?

— जेम्स एंडरसन

Answer 1

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

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

यह निश्चित रूप से एक कोड गंध होगा यदि आपके पास गुणों को संशोधित करने के लिए सिर्फ एक अलग वर्ग था Card- अगर यह उचित रूप से अपने आप की देखभाल करने की उम्मीद कर सकता है।

लेकिन क्या वास्तव में यह Cardजानने का काम है कि Playerयह किसके लिए दृश्यमान है?

और लागू क्यों Card.isVisibleTo(Player p), लेकिन नहीं Player.isVisibleTo(Card c)? या ठीक इसके विपरीत?

हां, आप इसके लिए किसी नियम के साथ आने का प्रयास कर सकते हैं, जैसा कि आपने किया था - जैसे कि (?) की Playerतुलना में अधिक उच्च स्तर पर होना Card- लेकिन यह अनुमान लगाने के लिए सीधा नहीं है और मुझे एक से अधिक स्थानों पर देखना होगा। विधि खोजने के लिए।

समय के साथ यह दोनों और वर्ग isVisibleToपर लागू करने के लिए एक सड़ा हुआ डिजाइन समझौता हो सकता है , जो मुझे लगता है कि एक नहीं-नहीं है। ऐसा क्यों? क्योंकि मैं पहले से ही शर्मनाक दिन की कल्पना करता हूं, जब मुझे लगता है कि इससे अलग मूल्य वापस आ जाएगा - यह व्यक्तिपरक है - इसे डिजाइन द्वारा असंभव बनाया जाना चाहिए । CardPlayerplayer1.isVisibleTo(card1)card1.isVisibleTo(player1).

कार्ड और खिलाड़ियों की आपसी दृश्यता को किसी प्रकार के संदर्भ ऑब्जेक्ट द्वारा नियंत्रित किया जाना चाहिए - यह हो Viewport, Dealया हो Game।

यह वैश्विक कार्यों के बराबर नहीं है। आखिरकार, कई समवर्ती खेल हो सकते हैं। ध्यान दें कि एक ही कार्ड का उपयोग कई तालिकाओं पर एक साथ किया जा सकता है। हम Cardकुदाल के प्रत्येक इक्का के लिए कई उदाहरण बना सकते हैं ?

मैं अभी भी लागू हो सकता है isVisibleToपर Card, लेकिन यह करने के लिए एक संदर्भ वस्तु गुजरती हैं और बनाने के Cardप्रतिनिधि क्वेरी। उच्च युग्मन से बचने के लिए इंटरफ़ेस का कार्यक्रम।

अपने दूसरे उदाहरण के रूप में - यदि दस्तावेज़ आईडी में केवल एक ही है BigDecimal, तो इसके लिए एक आवरण वर्ग क्यों बनाएं?

मैं कहता हूँ कि आप सभी की जरूरत है एक है DocumentRepository.getDocument(BigDecimal documentID);

वैसे, जावा से अनुपस्थित रहते हुए, structC # में हैं।

देख

• http://msdn.microsoft.com/en-us/library/ah19swz4.aspx

• http://msdn.microsoft.com/en-us/library/0taef578.aspx

सन्दर्भ के लिए। यह एक बहुत ही ऑब्जेक्ट-ओरिएंटेड भाषा है, लेकिन कोई इससे बाहर नहीं निकलता है।

Comments

सी # में संरचनाओं के बारे में बस एक नोट: वे कोई विशिष्ट संरचना नहीं हैं, जैसे कि आप उन्हें सी में जानते हैं। वास्तव में, वे विरासत, एनकैप्सुलेशन और बहुरूपता के साथ ओओपी का भी समर्थन करते हैं। कुछ ख़ासियतों के अलावा मुख्य अंतर यह है कि रनटाइम इंस्टेंस को कैसे संभालता है जब उन्हें अन्य ऑब्जेक्ट्स के लिए पास किया जाता है: संरचनाएं मूल्य प्रकार हैं और कक्षाएं संदर्भ प्रकार हैं!

— 15

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

— सुपरकैट

+1 के लिए "यह वैश्विक कार्यों के बराबर नहीं है।" यह दूसरों द्वारा बहुत संबोधित नहीं किया गया है। (हालांकि यदि आपके पास कई डेक हैं, तो एक वैश्विक फ़ंक्शन एक ही कार्ड के अलग-अलग उदाहरणों के लिए अलग-अलग मान लौटाएगा)।

— एलेक्सिस

@supercat यह एक अलग प्रश्न या एक चैट सत्र के योग्य है, लेकिन मुझे वर्तमान में कोई दिलचस्पी नहीं है :-( आप कहते हैं (C C में) "संरचनाएं जो इंटरफेस को लागू करती हैं, क्लास ऑब्जेक्ट्स से अलग व्यवहार करती हैं जो इसी तरह से" मैं सहमत हूं। विचार करने के लिए अन्य व्यवहारिक अंतर हैं, लेकिन निम्नलिखित में AFAIK Interface iObj = (Interface)obj;, का व्यवहार या की स्थिति से iObjप्रभावित नहीं होता है (सिवाय इसके कि अगर यह है तो उस असाइनमेंट पर एक बॉक्सिंग कॉपी होगी )।structclassobjstruct

— मार्क हर्ड

Answer 2

OOP के पीछे मूल विचार यह है कि डेटा और व्यवहार (उस डेटा पर) अविभाज्य हैं और वे एक वर्ग के ऑब्जेक्ट के विचार से युग्मित हैं।

आप यह मानने की सामान्य त्रुटि कर रहे हैं कि कक्षाएं OOP में एक मौलिक अवधारणा हैं। क्लासेस केवल एक विशेष रूप से लोकप्रिय तरीका है इनकैप्सुलेशन प्राप्त करना। लेकिन हम इसे स्लाइड करने की अनुमति दे सकते हैं।

मान लीजिए कि आपके पास एक सामान्य कार्ड गेम एपीआई है। आपके पास एक क्लास कार्ड है। अब इस कार्ड वर्ग को खिलाड़ियों को दृश्यता निर्धारित करने की आवश्यकता है।

अच्छा भारी सं। जब आप ब्रिज खेल रहे होते हैं तो क्या आप सात दिलों से पूछते हैं कि डमी के हाथ को गुप्त से बदलने का समय केवल डमी के नाम से जाना जाता है? बिलकूल नही। यह कार्ड की चिंता बिल्कुल नहीं है।

एक तरीका यह है कि कार्ड क्लास पर बूलियन को अदृश्य (प्लेयर पी) है। एक और खिलाड़ी खिलाड़ी वर्ग पर अदृश्य (कार्ड सी) है।

दोनों ही भयावह हैं; दोनों में से कोई भी मत करो। ब्रिज के नियमों को लागू करने के लिए न तो खिलाड़ी और न ही कार्ड जिम्मेदार हैं!

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

मैंने पहले कभी "व्यूपोर्ट" के साथ कार्ड नहीं खेला है, इसलिए मुझे नहीं पता कि इस वर्ग को क्या करना है। मैं है ताश के पत्तों की एक जोड़ी डेक, कुछ खिलाड़ियों, एक मेज, और Hoyle की एक प्रति के साथ कार्ड खेला। व्यूपोर्ट किस चीजों का प्रतिनिधित्व करता है?

हालाँकि यह दृष्टिकोण कार्ड और प्लेयर दोनों वर्गों के एक संभावित सदस्य फ़ंक्शन को लूटता है।

अच्छा!

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

नहीं; OOP का मूल विचार यह है कि वस्तुएं अपनी चिंताओं को कूटबद्ध करती हैं । आपके सिस्टम में एक कार्ड के बारे में ज्यादा चिंता नहीं है। न ही कोई खिलाड़ी है। ऐसा इसलिए है क्योंकि आप दुनिया का सटीक रूप से मॉडलिंग कर रहे हैं । वास्तविक दुनिया में, गुण एक खेल के लिए प्रासंगिक कार्ड हैं जो अत्यधिक सरल हैं। हम कार्ड पर चित्रों को 1 से लेकर 52 तक की संख्या में बदल सकते हैं, बिना गेम को खेले बिना। हम खेल के खेल को ज्यादा बदले बिना उत्तर, दक्षिण, पूर्व और पश्चिम के लेबल वाले चार लोगों को बदल सकते हैं। कार्ड गेम की दुनिया में खिलाड़ी और कार्ड सबसे सरल चीजें हैं। नियम वे हैं जो जटिल हैं, इसलिए नियमों का प्रतिनिधित्व करने वाला वर्ग वह है जहां जटिलता होनी चाहिए।

अब, यदि आपका कोई खिलाड़ी AI है, तो उसकी आंतरिक स्थिति बेहद जटिल हो सकती है। लेकिन एअर इंडिया यह निर्धारित नहीं करता है कि यह एक कार्ड देख सकता है या नहीं। नियम यह निर्धारित करते हैं ।

यहां बताया गया है कि मैं आपका सिस्टम कैसे डिजाइन करूंगा।

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

अगला, एक खिलाड़ी की प्रकृति क्या है? एक खिलाड़ी दृश्य क्रियाओं के क्रम का उपभोग करता है और एक क्रिया का निर्माण करता है ।

नियम वस्तु वह है जो इस सबका समन्वय करता है। नियम दृश्य क्रियाओं का एक क्रम उत्पन्न करते हैं और खिलाड़ियों को सूचित करते हैं:

• खिलाड़ी एक, दसों दिलों को खिलाड़ी तीन ने आपको सौंप दिया है।
• खिलाड़ी दो, एक कार्ड खिलाड़ी तीन द्वारा खिलाड़ी को सौंप दिया गया है।

और फिर खिलाड़ी से कार्रवाई के लिए कहता है।

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

और इसी तरह।

अपनी नीतियों से अपने तंत्र को अलग करें । खेल की नीतियों को एक पॉलिसी ऑब्जेक्ट में समझाया जाना चाहिए , कार्ड में नहीं । कार्ड सिर्फ एक तंत्र हैं।

Comments

@gnat: एलन के से एक विपरीत राय है "वास्तव में मैंने" ऑब्जेक्ट-ओरिएंटेड "शब्द बनाया है, और मैं आपको बता सकता हूं कि मेरे पास सी ++ नहीं था।" ओओ भाषाएं हैं जिनमें कोई भी वर्ग नहीं है; जावास्क्रिप्ट दिमाग में आता है।

— एरिक लिपर्ट

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

— एरिक लिपर्ट

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

— श्वर्न

इसे इस तरह से समझें: वास्तविक दुनिया में वास्तविक कार्ड क्या व्यवहार करता है? मुझे लगता है कि जवाब "कोई नहीं है।" अन्य चीजें कार्ड पर कार्य करती हैं। वास्तविक दुनिया में कार्ड ही, शाब्दिक रूप से केवल जानकारी (4 क्लबों का) है, जिसमें किसी भी प्रकार का कोई आंतरिक व्यवहार नहीं है। कैसे उस जानकारी (उर्फ "ए कार्ड") का उपयोग किसी चीज / किसी और व्यक्ति, "नियम" और "खिलाड़ियों" के लिए 100% तक किया जाता है। एक ही कार्ड का उपयोग अनंत (अच्छी तरह से, शायद काफी नहीं) विभिन्न खेलों के लिए किया जा सकता है, विभिन्न खिलाड़ियों की किसी भी संख्या से। एक कार्ड सिर्फ एक कार्ड है, और इसके सभी गुण हैं।

— क्रेग

@ मॉन्टैजिस्ट: मुझे चीजों को थोड़ा स्पष्ट करने दो। सी। पर विचार करें। मुझे लगता है कि आप सहमत होंगे कि सी में कक्षाएं नहीं हैं। हालाँकि, आप कह सकते हैं कि संरचनाएं "वर्ग" हैं, आप फ़ंक्शन पॉइंटर प्रकार के क्षेत्र बना सकते हैं, आप vtables का निर्माण कर सकते हैं, आप "कंस्ट्रक्टर" नामक विधियाँ बना सकते हैं जो vtables सेट करते हैं ताकि कुछ संरचनाएं एक दूसरे से "विरासत में मिली" हों। और इसी तरह। आप कर सकते हैं का अनुकरण सी में वर्ग आधारित विरासत और आप कर सकते हैं का अनुकरण जे एस में यह। लेकिन ऐसा करने का मतलब है कि भाषा का शीर्ष पर कुछ बनाना जो पहले से नहीं है।

— एरिक लिपर्ट

Answer 3

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

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

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

• एक वस्तु उन्मुख तरीके से फाइबोनैचि अनुक्रम की गणना करने पर विचार करें । मैं ऐसा करने के लिए एक समझदार तरीके के बारे में नहीं सोच सकता; सरल संरचित प्रोग्रामिंग इस समस्या का सबसे अच्छा समाधान प्रदान करती है।

• आपका isVisibleसंबंध दोनों वर्गों से है, या न तो, या वास्तव में: संदर्भ के लिए । व्यवहारविहीन रिकॉर्ड एक कार्यात्मक या प्रक्रियात्मक प्रोग्रामिंग दृष्टिकोण के विशिष्ट हैं, जो आपकी समस्या के लिए सबसे अच्छा लगता है। कुछ भी गड़बड़ नहीं है

  static boolean isVisible(Card c, Player p);
  

  और इसके Cardआगे rankऔर तरीके नहीं होने से कुछ भी गलत नहीं है suit।

Comments

@UMAD हां, यह बिल्कुल मेरी बात है, और इसमें कुछ भी गलत नहीं है। काम के लिए सही <del> भाषा </ del> प्रतिमान का उपयोग करें । (वैसे, स्मॉलटाक के अलावा अधिकांश भाषाएं शुद्ध ऑब्जेक्ट-ओरिएंटेड नहीं हैं। उदाहरण के लिए, जावा #, C # और C ++ अनिवार्य, संरचित, प्रक्रियात्मक, मॉड्यूलर, कार्यात्मक और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का समर्थन करती हैं। वे सभी गैर-OO प्रतिमान एक कारण से उपलब्ध हैं। : ताकि आप उनका इस्तेमाल कर सकें)

— amon

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

— श्वर्न

@ अगर कुछ भी Fibonacciसार वर्ग का एक उपवर्ग है Sequence, अनुक्रम किसी भी संख्या सेट द्वारा उपयोग किया जाता है और बीज, राज्य, कैशिंग और एक पुनरावृत्ति भंडारण के लिए जिम्मेदार है।

— जॉर्ज रीथ

मुझे उम्मीद नहीं थी कि "शुद्ध OOP फाइबोनैचि" nerd-sniping में इतना प्रभावी होगा । कृपया इन टिप्पणियों में इसके बारे में किसी भी परिपत्र चर्चा को रोक दें, हालांकि इसका एक निश्चित मनोरंजन मूल्य था। अब चलो सब कुछ एक बदलाव के लिए रचनात्मक करते हैं!

— अमन

रिटर्न्स को पूर्णांक की विधि बनाने के लिए यह मूर्खतापूर्ण होगा, बस आप इसे OOP कह सकते हैं। यह एक फंक्शन है और इसे एक फंक्शन की तरह माना जाना चाहिए।

— इबिबिस

Answer 4

OOP के पीछे मूल विचार यह है कि डेटा और व्यवहार (उस डेटा पर) अविभाज्य हैं और वे एक वर्ग के ऑब्जेक्ट के विचार से युग्मित हैं। ऑब्जेक्ट में डेटा और विधियाँ हैं जो उस (और अन्य डेटा) के साथ काम करती हैं। ओओपी के सिद्धांतों द्वारा स्पष्ट रूप से, ऑब्जेक्ट जो केवल डेटा (जैसे सी संरचनाएं) हैं, उन्हें एक विरोधी पैटर्न माना जाता है। (...) यह स्पष्ट रूप से OOP के प्रमुख विचार के खिलाफ है।

यह एक कठिन सवाल है क्योंकि यह काफी दोषपूर्ण परिसर पर आधारित है:

1. यह विचार कि OOP कोड लिखने का एकमात्र वैध तरीका है।
2. विचार है कि OOP एक अच्छी तरह से परिभाषित अवधारणा है। यह एक ऐसी चर्चा बन गया है कि दो लोगों को ढूंढना मुश्किल है जो ओओपी के बारे में सहमत हो सकते हैं।
3. OOP डेटा और व्यवहार के बारे में है।
4. यह विचार कि सब कुछ है / एक अमूर्त होना चाहिए।

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

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

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

आप isVisibleइस Cardप्रकार की कोई विधि नहीं बनाएंगे क्योंकि दिखाई देना संभवतः आपके कार्ड की धारणा के लिए आवश्यक नहीं है (जब तक कि आपके पास बहुत विशेष कार्ड न हों जो पारभासी या अपारदर्शी हो सकते हैं ...)। क्या यह Playerप्रकार की एक विधि होनी चाहिए ? ठीक है, कि शायद खिलाड़ियों की एक परिभाषित गुणवत्ता नहीं है। क्या यह किसी Viewportप्रकार का हिस्सा होना चाहिए ? एक बार फिर यह निर्भर करता है कि आप किस व्यूपोर्ट को परिभाषित करते हैं और क्या कार्ड की दृश्यता की जांच करने की धारणा व्यूपोर्ट को परिभाषित करने के लिए अभिन्न है।

यह बहुत संभव है isVisibleबस एक नि: शुल्क फ़ंक्शन होना चाहिए।

Comments

माइंडलेस ड्रोनिंग के बजाय सामान्य ज्ञान के लिए +1।

— राइटहोल्ड

मैंने जो पंक्तियाँ पढ़ी हैं, उससे आप जिस निबंध से जुड़े हैं, वह उस तरह का है जैसे एक ठोस पाठ जो मैंने थोड़ी देर में पढ़ा नहीं है।

— आर्थर हैवलिसक

@ArthurHavlicek यदि आप कोड नमूने में उपयोग की जाने वाली भाषाओं को नहीं समझते हैं, तो इसका पालन करना कठिन है, लेकिन मैंने इसे काफी रोशन पाया।

— डोभाल

Answer 5

ओओपी के सिद्धांतों द्वारा स्पष्ट रूप से, ऑब्जेक्ट जो केवल डेटा (जैसे सी संरचनाएं) हैं, उन्हें एक विरोधी पैटर्न माना जाता है।

नहीं, वे नहीं हैं। सादा-पुराने-डेटा ऑब्जेक्ट एक पूरी तरह से मान्य पैटर्न हैं, और मैं उनसे ऐसे किसी भी कार्यक्रम की उम्मीद करूंगा जो आपके डेटा के विभिन्न क्षेत्रों के बीच निरंतर या संचारित होने वाले डेटा से संबंधित है।

जब आपका डेटा-लेयर टेबल से पढ़ते समय एक पूरी कक्षा को स्पूल कर सकता है, तो यह केवल एक सामान्य डेटा लाइब्रेरी हो सकती है, जो टेबल से फ़ील्ड्स के साथ एक POD लौटाती है, जो इसे आपके प्रोग्राम के किसी अन्य क्षेत्र में बदल देती है जो परिवर्तित हो जाता है आपके ठोस वर्ग के लिए एक खिलाड़ी POD ।PlayerPlayersPlayer

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

Comments

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

— pdr

वास्तव में, कार्ड और दस्तावेज़ वास्तविक दुनिया में भी जानकारी के कंटेनर हैं और किसी भी "पैटर्न" को जो इसे संभाल नहीं सकता है उसे अनदेखा करने की आवश्यकता है।

— जेफ़ओ

Plain-Old-Data objects are a perfectly valid pattern मैंने नहीं कहा कि वे नहीं थे, मैं कह रहा हूं कि यह गलत है जब वे आवेदन के पूरे निचले आधे हिस्से को आबाद करते हैं।

— 12

Answer 6

व्यक्तिगत रूप से मुझे लगता है कि डोमेन संचालित डिज़ाइन इस मुद्दे पर स्पष्टता लाने में मदद करता है। मैं जो सवाल पूछता हूं, वह यह है कि मैं इंसानों को कार्ड गेम कैसे बताता हूं? दूसरे शब्दों में, मैं क्या मॉडलिंग कर रहा हूं? यदि मैं वास्तव में मॉडलिंग कर रहा हूं, तो "व्यूपोर्ट" शब्द और एक अवधारणा शामिल है जो इसके व्यवहार से मेल खाती है, तो मैं व्यूपोर्ट ऑब्जेक्ट बनाऊंगा और यह वही करना चाहिए जो इसे तार्किक रूप से करना चाहिए।

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

मॉडल शब्द का अर्थ है कि आप किसी चीज़ का प्रतिनिधित्व कर रहे हैं। मैं उस कक्षा में डालने के प्रति सावधानी बरतता हूं जो उस चीज से परे है जो आप प्रतिनिधित्व कर रहे हैं।

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

Comments

ऊपर लिप्टर्ट का जवाब इस अवधारणा का एक बेहतर उदाहरण है।

— रिबेल्डेदी

Answer 7

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

यह कैसे लागू होता है Card- Playerसमस्या: ViewPortयदि आप सोचते हैं Cardऔर Playerदो स्वतंत्र पुस्तकालयों के रूप में (जो Playerकभी-कभी बिना उपयोग किया जाता है Card) होने पर एक अमूर्त बनाना समझ में आता है । हालांकि, मुझे लगता है कि एक Playerहोल्ड के लिए इच्छुक हूं Cardsऔर Collection<Card> getVisibleCards ()उन्हें एक एक्सेसर प्रदान करना चाहिए । इन दोनों समाधान ( ViewPortऔर मेरा) उपलब्ध कराने से बेहतर हैं isVisibleकी एक विधि के रूप में Cardया Playerसमझा जा सकता कोड रिश्ते बनाने के मामले में,।

एक बाहर का वर्ग समाधान, के लिए बहुत बेहतर है DocumentId। बनाने के लिए बहुत कम प्रेरणा है (मूल रूप से, पूर्णांक) एक जटिल डेटाबेस लाइब्रेरी पर निर्भर करता है।

Comments

मुझे आपका ब्लॉग पसंद है।

— RokL

Answer 8

मुझे यकीन नहीं है कि सवाल का सही स्तर पर जवाब दिया जा रहा है। मैंने मंच में बुद्धिमान से आग्रह किया था कि वह यहां प्रश्न के मूल पर सक्रिय रूप से सोचें।

यू मैड एक ऐसी स्थिति ला रहा है, जहां उनका मानना ​​है कि ओओपी के बारे में उनकी समझ के अनुसार प्रोग्रामिंग आमतौर पर बहुत सारे पत्तों के नोड्स के डेटा धारक होंगे, जबकि उनके ऊपरी स्तर के एपीआई में अधिकांश व्यवहार शामिल होते हैं।

मुझे लगता है कि यह विषय थोड़ा विवादास्पद है कि क्या अदृश्य बनाम कार्ड बनाम प्लेयर पर परिभाषित किया जाएगा; यह केवल एक उदाहरण था, यद्यपि भोला था।

हालांकि हाथ में समस्या को देखने के लिए मैंने यहां अनुभवी को धक्का दिया था। मुझे लगता है कि एक अच्छा सवाल है जिसे यू मैड ने आगे बढ़ाया है। मैं समझता हूं कि आप नियमों और संबंधित तर्क को किसी वस्तु के लिए धक्का देंगे; लेकिन जैसा कि मैं समझता हूं कि सवाल यह है

1. क्या साधारण डेटा धारक का निर्माण करना ठीक है (कक्षाएं / संरचनाएं? मुझे इस बात की परवाह नहीं है कि वे इस प्रश्न के लिए क्या मॉडल हैं) जो वास्तव में बहुत कार्यक्षमता प्रदान नहीं करते हैं?
2. यदि हाँ, तो उन्हें मॉडल करने का सबसे अच्छा या पसंदीदा तरीका क्या है?
3. यदि नहीं, तो हम इस डेटा काउंटर भागों को उच्च एपीआई कक्षाओं (व्यवहार सहित) में कैसे शामिल करते हैं

मेरे विचार:

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

Comments

समस्या यह है कि प्रश्न (और आपका उत्तर) चीजों को "सामान्य रूप से" कैसे करना है। तथ्य यह है, हम कभी भी चीजों को "सामान्य रूप से" नहीं करते हैं। हम हमेशा विशिष्ट चीजें करते हैं। यह निर्धारित करने के लिए कि हमारी विशिष्ट चीजें स्थिति के लिए सही चीजें हैं या नहीं, हमारी विशिष्ट चीजों की जांच करना और उन्हें हमारी आवश्यकताओं के खिलाफ मापना आवश्यक है।

— जॉन सॉन्डर्स

@ जॉनसनर्स मैं यहां आपकी बुद्धिमत्ता का अनुभव करता हूं और एक हद तक सहमत हूं, लेकिन एक समस्या को संबोधित करने से पहले केवल वैचारिक दृष्टिकोण की आवश्यकता है। आखिर, यहाँ सवाल उतना खुला-खुला नहीं है जितना कि लगता है। मुझे लगता है कि यह एक वैध OOD प्रश्न है जो OOP के प्रारंभिक उपयोगों में किसी भी OO डिज़ाइनर चेहरे का है। तुम्हारा क्या लेना है? यदि एक सहमति में मदद मिलती है, तो हम आपकी पसंद का एक उदाहरण बनाने पर चर्चा कर सकते हैं।

— हर्षा

मैं अब 35 वर्षों से स्कूल से बाहर हूं। वास्तविक दुनिया में, मुझे "वैचारिक दृष्टिकोण" में बहुत कम मूल्य मिलता है। मुझे इस मामले में मेयर्स से बेहतर शिक्षक होने का अनुभव है।

— जॉन सॉन्डर्स

मैं वास्तव में व्यवहार भेद के लिए डेटा बनाम वर्ग के लिए वर्ग को नहीं समझता। यदि आप अपनी वस्तुओं को ठीक से सार करते हैं, तो कोई भेद नहीं है। फ़ंक्शन के Pointसाथ कल्पना करें getX()। आप कल्पना कर सकते हैं कि यह एक विशेषता है, लेकिन यह इसे डिस्क या इंटरनेट से भी पढ़ सकता है। प्राप्त करना और स्थापित करना व्यवहार है, और ऐसी कक्षाएं करना जो सिर्फ वही करते हैं जो पूरी तरह से ठीक है। डेटाबेस केवल डेटा को प्राप्त करते हैं और सेट करते हैं fwiw

— आर्थर हैवेलिस

@ArthurHavlicek: यह जानते हुए कि एक वर्ग क्या नहीं होगा ऐसा अक्सर बस के रूप में जानते हुए भी यह क्या करेंगे के रूप में उपयोगी है। अपने अनुबंध में कुछ निर्दिष्ट करने के बाद कि यह एक धारण करने योग्य अपरिवर्तनीय डेटा धारक से अधिक कुछ नहीं के रूप में व्यवहार करेगा, या गैर-साझा करने योग्य परिवर्तनशील डेटा धारक से अधिक कुछ नहीं के रूप में उपयोगी है।

— सुपरकैट

Answer 9

ओओपी में भ्रम का एक सामान्य स्रोत इस तथ्य से उपजा है कि कई वस्तुएं राज्य के दो पहलुओं को घेरती हैं: वे चीजें जिनके बारे में वे जानते हैं, और वे चीजें जिनके बारे में उन्हें पता है। वस्तुओं की स्थिति की चर्चा अक्सर बाद के पहलू को अनदेखा करती है, क्योंकि चौखटों में जहां ऑब्जेक्ट संदर्भों का उल्लेख होता है, यह निर्धारित करने का कोई सामान्य तरीका नहीं है कि किसी भी वस्तु के बारे में कौन सी चीजें पता हो सकती हैं, जिसका संदर्भ कभी भी बाहरी दुनिया के सामने आया है।

मेरा सुझाव है कि यह संभवतः एक CardEntityवस्तु के लिए सहायक होगा जो कार्ड के उन पहलुओं को अलग-अलग घटकों में संलग्न करता है। एक घटक कार्ड (जैसे "डायमंड किंग" या "लावा ब्लास्ट) के चिह्नों से संबंधित होगा; खिलाड़ियों के पास चकमा देने के लिए AC-3 मौका है, या फिर 2D6 क्षति उठाएं")। एक स्थिति के एक अनूठे पहलू से संबंधित हो सकता है जैसे स्थिति (जैसे यह डेक में है, या जो के हाथ में है, या लैरी के सामने की मेज पर है)। कोई तीसरा इसे देख सकता है (शायद कोई नहीं, शायद एक खिलाड़ी, या शायद कई खिलाड़ी)। यह सुनिश्चित करने के लिए कि सब कुछ सिंक में रखा गया है, ऐसे स्थान जहां एक कार्ड को सरल क्षेत्रों के रूप में समझाया नहीं जा सकता है, बल्कि CardSpaceवस्तुओं; एक कार्ड को एक स्थान पर ले जाने के लिए, यह उचित के लिए एक संदर्भ देगाCardSpaceवस्तु; यह फिर पुराने स्थान से खुद को हटा देगा और खुद को नए स्थान में डाल देगा)।

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

Answer 10

हालाँकि यह दृष्टिकोण कार्ड और प्लेयर दोनों वर्गों के एक संभावित सदस्य फ़ंक्शन को लूटता है।

और वह बुरा / अशुभ कैसे है?

अपने कार्ड उदाहरण के लिए एक समान सादृश्य का उपयोग करने के लिए, ए Car, Driverऔर आपको यह निर्धारित करने की आवश्यकता है कि क्या Driverड्राइव कर सकते हैं Car।

ठीक है, तो आप का फैसला किया है कि आप अपने नहीं करना चाहती Carहै, तो पता करने के लिए Driverसही गाड़ी की चाबी है या नहीं, और कुछ अज्ञात कारण से आप भी निर्णय लिया है कि आप अपने नहीं करना चाहती के लिए Driverके बारे में पता करने के लिए Carवर्ग (तुमने नहीं किया पूरी तरह से मांस यह आपके मूल प्रश्न में भी है)। इसलिए, आपके पास एक मध्यस्थ वर्ग है, एक Utilsवर्ग की तर्ज पर कुछ , जिसमें ऊपर दिए गए प्रश्न के लिए एक मूल्य वापस करने के लिए व्यावसायिक नियमों के साथ विधि शामिल booleanहै।

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