DoSomethingToThing (बात एन) बनाम Thing.DoSomething()

Question

किन कारणों से जो निर्धारित दृष्टिकोण और अधिक उपयुक्त है?

यहाँ

Answer 1

मुझे लगता है कि दोनों के पास उनके स्थान हैं।

आपको केवल DoSomethingToThing(Thing n) का उपयोग नहीं करना चाहिए क्योंकि आपको लगता है कि "कार्यात्मक प्रोग्रामिंग अच्छा है"। इसी तरह आपको Thing.DoSomething() का उपयोग नहीं करना चाहिए क्योंकि "ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग अच्छा है"।

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

उदाहरण के लिए, यदि 'वाक्य' का हिस्सा आप तनाव करना चाहते हैं तो वस्तु है, आपको ओओ शैली का उपयोग करना चाहिए।

उदाहरण:

fileHandle.close(); 

समय है जब आप के आसपास फ़ाइल हैंडल, मुख्य बात आप के बारे में फ़ाइल यह प्रतिनिधित्व करता है का ट्रैक रखने में सोच रहे हैं गुजर रहे हैं के अधिकांश।

counterexample:

string x = "Hello World"; 
submitHttpRequest(x); 

इस मामले HTTP अनुरोध प्रस्तुत करने में स्ट्रिंग जो शरीर है तुलना में कहीं अधिक महत्वपूर्ण है, इसलिए submitHttpRequst(x)x.submitViaHttp()

कहने की जरूरत नहीं करने के लिए बेहतर है, इन परस्पर नहीं हैं अनन्य। आपके पास वास्तव में

networkConnection.submitHttpRequest(x) 

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

Answer 2

लगभग पर्याप्त जानकारी नहीं है। यह निर्भर करता है कि आपकी भाषा "Thing.something" या समकक्ष (यानी यह एक ओओ भाषा है) का समर्थन करती है। यदि ऐसा है, तो यह कहीं अधिक उपयुक्त है क्योंकि यह ओओ प्रतिमान है (सदस्यों को उस वस्तु से जोड़ा जाना चाहिए जिस पर वे कार्य करते हैं)। http://www.pragmaticprogrammer.com/articles/tell-dont-ask: एक प्रक्रियात्मक शैली में, जाहिर है, DoSomethingtoThing() अपने एकमात्र विकल्प है ... या ThingDoSomething()

Answer 3

वस्तु उन्मुख होने के लिए, बताओ, नहीं पूछते है।

तो, Thing.DoSomething() के बजाय DoSomethingToThing (बात एन)।

Answer 4

DoSomethingToThing (बात एन) जबकि Thing.DoSomething एक कार्यात्मक दृष्टिकोण() के और अधिक हो सकता है एक वस्तु उन्मुख दृष्टिकोण के अधिक होगी।

Answer 5

बनाम प्रक्रियात्मक प्रोग्रामिंग पसंद :)

उन्मुखी वस्तु है कि मुझे लगता है कि अच्छी तरह से प्रलेखित OO फायदे Thing.DoSomething()

Answer 6

आप एक बात की आंतरिक स्थिति साथ काम कर रहे हैं पर लागू होते हैं, Thing.DoSomething() अधिक समझ में आता है, क्योंकि यदि आप चीज के आंतरिक प्रतिनिधित्व को बदलते हैं, या यह कैसे काम करता है, तो उसमें बात करने वाले कोड को बदलने की ज़रूरत नहीं है। यदि आप चीजों के संग्रह से निपट रहे हैं, या कुछ उपयोगिता विधियों को लिख रहे हैं, तो प्रक्रियात्मक-शैली DoSomethingToThing() अधिक समझदार हो सकती है या अधिक सीधे आगे हो सकती है; लेकिन अभी भी है, आमतौर पर उद्देश्य यह है कि संग्रह का प्रतिनिधित्व करने पर एक विधि के रूप में प्रतिनिधित्व किया जा सकता है: उदाहरण के

GetTotalPriceofThings(); 

के लिए बनाम

Cart.getTotal(); 

यह वास्तव में कैसे वस्तु उन्मुख अपने कोड है पर निर्भर करता है।

Answer 7

यह Design question: does the Phone dial the PhoneNumber, or does the PhoneNumber dial itself on the Phone?

Answer 8

से कहा है कि कर दिया गया यहाँ कारकों में से एक जोड़े को विचार करने के लिए:

• आप को संशोधित करने या Thing वर्ग का विस्तार कर सकते हैं। यदि नहीं, तो का उपयोग पूर्व
• Thing instantiated जा सकता है। यदि नहीं, तो एक स्थिर विधि
• तो Thing वास्तव में संशोधित हो (अर्थात गुण है कि बदल गया है) के रूप में बाद में उपयोग उत्तरार्द्ध पसंद करते हैं। यदि Thing संशोधित नहीं किया गया है, तो बाद में स्वीकार्य है।
• अन्यथा, जैसे वस्तुएं असली दुनिया वस्तु पर नक्शा लगाने के लिए हैं, वास्तविकता में अधिक जमीन लगने वाली विधि का चयन करें।

Answer 9

भले ही आप ओओ भाषा में काम नहीं कर रहे हों, जहां आपके पास चीज होगी।DoSomething(), अपने कोड के समग्र पठनीयता के लिए, जैसे कार्यों का एक सेट होने:

ThingDoSomething() ThingDoAnotherTask() ThingWeDoSomethingElse()

तो

AnotherThingDoSomething()

और इतने पर बेहतर है।

"थिंग" पर काम करने वाले सभी कोड एक स्थान पर हैं। बेशक, "DoSomething" और अन्य कार्यों को लगातार नामित किया जाना चाहिए - इसलिए आपके पास ThingOneRead(), एक ThingTwoRead() है ... अब तक आपको बिंदु प्राप्त करना चाहिए। जब आप बारह महीनों के समय कोड पर काम पर वापस जाते हैं, तो आप चीजों को तार्किक बनाने के लिए समय निकालने की सराहना करेंगे।

Answer 10

सामान्य रूप से, यदि "कुछ" एक ऐसी क्रिया है जो "चीज़" स्वाभाविक रूप से जानता है कि कैसे करना है, तो आपको चीज़ का उपयोग करना चाहिए। कुछ()। यह अच्छा ओओ encapsulation है, क्योंकि अन्यथा DoSomethingToThing (चीज) "चीज़" की संभावित आंतरिक जानकारी तक पहुंचने के लिए होगा।

उदाहरण invoice.getTotal के लिए()

तो "कुछ" स्वाभाविक रूप से की "बात की" डोमेन मॉडल हिस्सा नहीं है, तो एक ही विकल्प एक सहायक विधि का उपयोग करने के लिए है।

उदाहरण के लिए: Logger.log (चालान)

Answer 11

तो DoingSomething एक वस्तु के लिए एक और परिदृश्य में एक अलग परिणाम प्राप्त होने की संभावना है, तो मैं oneThing.DoSomethingToThing आप सुझाव देंगे (anotherThing)।

उदाहरण के लिए आपके पास प्रोग्राम में दो चीजें सहेजने वाली चीजें हो सकती हैं ताकि आप डेटाबेस ऑब्जेक्ट सेव कर सकें। चीज़ (चीज़) सत्र ऑब्जेक्ट। सेव (चीज) चीज़ की तुलना में अधिक फायदेमंद होगी। सहेजें() या चीज़। सेवटोडाबेस या चीज़ .SaveToSession()।

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

Answer 12

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

Collection.Add(Thing) 

की तुलना में बेहतर

Thing.AddSelfToCollection(Collection) 

है और अगर आप बात नहीं लिखा था, और एक व्युत्पन्न वर्ग नहीं बना सकते, तो आप कोई chocie लेकिन क्या करना है DoSomething (बात)

Answer 13

1. Thing.DoSomething उचित है अगर बात आपके वाक्य का विषय है।
   • DoSomethingToThing (बात एन) उचित है अगर बात अपने वाक्य की वस्तु है।
   • ThingA.DoSomethingToThingB (ThingB m) एक अपरिहार्य संयोजन है, क्योंकि सभी भाषाओं में मैं सोच सकता हूं कि कार्य एक वर्ग से संबंधित हैं और परस्पर स्वामित्व नहीं हैं। लेकिन यह समझ में आता है क्योंकि आपके पास कोई विषय और वस्तु हो सकती है।

सक्रिय आवाज कर्म वाच्य की तुलना में अधिक स्पष्ट है, तो सुनिश्चित करें कि आपके वाक्य एक विषय है कि सिर्फ "कंप्यूटर" नहीं दे रहा है बनाते हैं। इसका मतलब है, फॉर्म 1 और फॉर्म 3 का उपयोग अक्सर करें, और शायद ही कभी फॉर्म 2 का उपयोग करें।

स्पष्टता के लिए:

// Form 1: "File handle, close." 
fileHandle.close(); 

// Form 2: "(Computer,) close the file handle." 
close(fileHandle); 

// Form 3: "File handle, write the contents of another file handle." 
fileHandle.writeContentsOf(anotherFileHandle); 

Answer 14

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

Answer 15

मैं मानता हूँ के साथ Kevin Conner

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

Answer 16

मैं ओरियन से सहमत हूं, लेकिन मैं निर्णय प्रक्रिया को फिर से लिखने जा रहा हूं।

आपके पास एक संज्ञा और क्रिया/वस्तु और एक क्रिया है।

• यदि इस प्रकार की कई वस्तुएं इस क्रिया का उपयोग करती हैं, तो ऑब्जेक्ट का क्रिया भाग बनाने का प्रयास करें।
• अन्यथा, कार्रवाई को अलग से समूहबद्ध करने का प्रयास करें, लेकिन संबंधित कार्यों के साथ।

मुझे फ़ाइल/स्ट्रिंग उदाहरण पसंद हैं। कई स्ट्रिंग ऑपरेशंस हैं, जैसे कि "SendAsHTTPReply", जो आपकी औसत स्ट्रिंग के लिए नहीं होगा, लेकिन अक्सर एक निश्चित सेटिंग में होता है। हालांकि, आप मूल रूप से एक फ़ाइल (उम्मीद है) को हमेशा बंद कर देंगे, इसलिए क्लास इंटरफ़ेस में बंद क्रिया को रखने के लिए यह सही समझ में आता है।

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