ऑब्जेक्ट ओरिएंटेड स्टाइल प्रोग्रामिंग ऑब्जेक्ट्स के बीच बातचीत के लिए

Question

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

परिदृश्य: व्यक्ति (जॉन) व्यक्ति (बेट्टी) देता है $ 5.

संभावित समाधान (छद्म कोड):

ए) John.pays (बेट्टी, 5);
बी) बेट्टी.रेसीव्स (जॉन, 5);
सी) बैंक। ट्रांसफर (जॉन, बेट्टी, 5);
डी)
लेनदेन शुरू करें:
जॉन.डेक्रेज (5);
Betty.increase (5);
अंत लेनदेन:
ई) सेवा। ट्रांसफर मॉनी (जॉन, बेट्टी, 5); // सेवा एक सामान्य सेवा वस्तु

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

धन्यवाद।

Answer 1

मेरा वोट: सी कहां सी करता है डी (उदाहरण के लिए पैसा नहीं खोता है)।

इस छोटे से उदाहरण में, "बैंक" एक पूरी तरह से मान्य इकाई है जो जानता है कि जॉन और बेट्टी के पास कितना पैसा है। न तो जॉन और न ही बेटी बैंक से झूठ बोलने में सक्षम होना चाहिए।

स्थिति के लिए आवश्यक "ओओ" कार्यक्रम में तर्क को उलटा (या नहीं) डरोने से डरो मत।

Answer 2

आपको अपने डोमेन के अनुसार मॉडल करना चाहिए। विकल्प सी सबसे अच्छा विकल्प दिखता है क्योंकि यह लेनदेन तर्क को बैंक \ सेवा कक्षा में अलग करेगा।

Answer 3

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

Answer 4

मैं ऊपर :)

जॉन क्यों दे रही है बेटी से कोई भी के लिए मतदान होगा? यह एक महत्वपूर्ण सवाल है, क्योंकि यह बताता है कि प्रवेश बिंदु कहां है। मान लें कि जॉन बेट्टी पैसे का भुगतान करता है, और यह payday है।

public class John 
{ 
    public void onPayday() 
    { 
     Betty.Receive(5.0f); 
    } 
} 

यह है कि यदि आप शुद्ध वस्तु-इंटरैक्शन शैली दृष्टिकोण के साथ निश्चित रूप से जाना चाहते हैं।

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

यह नियंत्रण का एक बड़ा उदाहरण है जिसका मतलब है - वस्तुएं कुछ बाहरी दिनचर्या में छेड़छाड़ की बजाय एक दूसरे के साथ बातचीत कर रही हैं। यह टेल का एक उदाहरण है, पूछो मत, क्योंकि बताते हुए एक दूसरे चीजें हैं (जॉन को इसका वेतन दिवस बताया गया था, जॉन ने 5 डॉलर स्वीकार करने के लिए बेटी को बताया)।

Answer 5

यहां कई वैकल्पिक समाधान हैं। उदाहरण के लिए,

Betty.Receieves(John.Gives(5))

इसका मतलब यह है देता है कि समारोह अवधि दी गयी है देता है।

tx = CashTransaction(John, Betty); 
tx.Transfer(5); 

इसमें यह माना जाता पहले prameter Payor है, और दूसरा आदाता है, तो आप नई वस्तुओं बनाने के बिना अनेक लेन-देन कर सकते हैं।

चीजों को कई तरीकों से मॉडलिंग किया जा सकता है। आपको उस मॉडल को चुनना चाहिए जो आप मॉडल के लिए प्रयास करने की कोशिश कर रहे हैं।

Answer 6

तुम सच में OOPy प्राप्त करना चाहते हैं, और अधिक लिखित भाषा की तरह कोड बनाने के लिए नहीं किया गया है निम्नलिखित

Person  Betty,John; 
CashTransfer PocketMoney; 
PocketMoney.from = John; 
PocketMoney.to  = Betty; 
PocketMoney.amount = 20.00; 
PocketMoney.transfer(); 

OOP की बात की कोशिश, लेकिन विभिन्न तरीकों और कोड अधिक बनाने के लिए मानकों के साथ वस्तुओं के लिए पठनीय।

तो उपर्युक्त कोड से, आप देख सकते हैं कि जॉन पॉकेट पैसों में बेटी $ 20 दे रहा है। कोड सार्थक है, आसान कोड पठनीयता, साथ ही समझदारी के लिए अनुमति देता है।

Answer 7

एक बात मैंने देखा है कि ओओपी के लिए नए लोग भौतिक संसार को उनके द्वारा लिखे गए कोड में मैप करने की कोशिश में पकड़े जाते हैं। क्या आप वास्तव में परवाह करते हैं कि जॉन और बेट्टी लोग हैं या आप वास्तव में बैंक खाते को चित्रित करना चाहते हैं? मुझे लगता है कि उदाहरण में वस्तुओं की आपकी पसंद वास्तव में समस्या के समाधान को समझना कठिन बनाती है।

इस के महत्वपूर्ण भाग 1) धन को कैसे स्थानांतरित करने के तर्क को कहां रखा जाए। 2) डेटा को स्टोर करने के लिए प्रत्येक व्यक्ति के पास कितना पैसा है।

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

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

Answer 8

क्या मैं अब एक प्रश्न पूछ सकता हूं? पैसे कौन नियंत्रित करता है? क्या जॉन लेनदेन की राशि तय करता है, बेटी करता है, या कुछ अनिर्दिष्ट तृतीय पक्ष करता है?

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

tx transaction_request = John.WantsToBuyFor(5); //check if John can 
if(Betty.AgreesWith(transaction_request))  //check if Betty wants 
{ 
    transaction_request.FinalizeWith(Betty);  //Do it with Betty 
} 

और FinalizeWith समारोह की तरह कुछ गणित

void FinalizeWith(Person party) 
{ 
    requestor.cash -= amount; 
    party.cash += amount; 
{ 

बेशक आप कुछ विवरण जोड़ने के लिए चाहते हो सकता है के

क्या करता है आइटम के जॉन खरीद है।

Answer 9

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

एक जाल आपको यह सुनिश्चित करना होगा कि आप इसमें शामिल न हों, हालांकि, this one है। यहां दिए गए उत्तरों को पढ़ें। आपको बहुत अच्छी सलाह मिलेगी। (उस सलाह पर अधिक ध्यान दें जिसे बहुत वोट दिया गया है।) एक बार जब आप उन्हें पढ़ और समझ चुके हैं, read Steve Yegge's rant (और इसे समझें!) भी। यह आपको लंबे समय तक सैनिटी बचाएगा।

Answer 10

OOP के लिए नए होने के नाते और अंत में कुछ OOP का उपयोग कर, मैं कहता हूँ चाहते हैं कि यह होना चाहिए ए और बी

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

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

आप दो व्यक्ति वस्तुएं बनाते हैं: बेट्टी और जॉन। तदनुसार विधियों का प्रयोग करें। John.sends की तरह (बेट्टी, 5)। इससे बेट्टी बननी चाहिए और बेटी की शेष राशि भी अपडेट करनी चाहिए।

क्या होगा यदि वे बैंक का उपयोग करना चाहते हैं? एक और तरीका जोड़ें, कहें ... स्थानांतरण (एसीटी) जो कुछ भी है।

यही मुझे लगता है।

Answer 11

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

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

FOTC एक समाधान है कि कुछ अन्य वर्गों में शामिल हैं की शुरुआत है:

• sealers & unsealers,
• पर्स, जो कि वे पैसे को शामिल में खातों की तरह एक छोटे से कर रहे हैं लेकिन जरूरी नहीं है मालिक।
• टकसालों, जो केवल चीजें हैं जो सकारात्मक शेष राशि

एक टकसाल एक सीलर/unsealer जोड़ी है, जो इसे एक पर्स के लिए endows जब भी टकसाल एक बनाता है के साथ पर्स बना सकते हैं। पीछा संतुलन परिवर्तन की निगरानी; संतुलन कम करते समय वे सीलर का उपयोग करते हैं, और एक पर्स से दूसरे पर्स में स्थानांतरित करने के लिए अदृश्य। पर्स खाली पर्स पैदा कर सकते हैं। Sealers & unsealers के उपयोग के कारण, एक पर्स केवल उसी टकसाल द्वारा बनाए गए अन्य पर्स के साथ काम करता है। कोई नकली नकल करने के लिए अपना खुद का पर्स नहीं लिख सकता है; एक टकसाल के उपयोग के साथ केवल एक वस्तु पैसा बना सकती है। मिंटों तक पहुंच सीमित करके नकली रोक दी जाती है।

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

इस प्रणाली में पैसे बनाने के लिए मौद्रिक प्राधिकरण (जो एक या एक से अधिक मिनटों के संदर्भ रखता है) जैसे कुछ महत्वपूर्ण विवरण गायब हैं।

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