किसी फ़ंक्शन में ऑर्डर करने के लिए सबसे अच्छा अभ्यास क्या है?

Question

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

क्या ऐसा करने के लिए इससे अच्छा तरीका है? क्या स्पष्टता को बढ़ाने वाले मापदंडों को आदेश देने का एक "सर्वोत्तम अभ्यास" तरीका है?

Comments

नामित पैरामीटर इसे किसी समस्या से कम बनाते हैं। अजगर इसे चरम पर ले जाता है, इसे देखें। एक अच्छा उदाहरण सी # में है - कॉल करने के कई तरीके MessageBox.Show। उस पर भी गौर करें।

— जॉब

हास्केल में, आंशिक फ़ंक्शन अनुप्रयोग की संभावित उपयोगिता आमतौर पर एक प्राकृतिक तर्क आदेश देने का सुझाव देती है।

— tdammers

आप मापदंडों की एक सभ्य राशि पर क्या विचार करेंगे?

— क्रिस

मैं सोच रहा था> 2. हालांकि मुझे लगता है कि ऑर्डर करने के लिए 2 सभी समान पैरामीटर लागू होते हैं।

— केसी पैटन

@ यह किसी भी भाषा के लिए सही है, जिसे करी

— jk के

Answer 1

सामान्य तौर पर: इसका उपयोग करें ।

अपने फ़ंक्शन के लिए एक परीक्षण लिखें, एक वास्तविक विश्व परीक्षण।
कुछ आप वास्तव में उस फ़ंक्शन के साथ करना चाहते हैं ।

और देखें कि आपने उन्हें किस क्रम में रखा है।

जब तक आपके पास पहले से ही (या पता है) कुछ फ़ंक्शन जो कुछ समान करते हैं।
उस मामले में: वे जो पहले से करते हैं, उसके अनुरूप कम से कम पहले तर्कों के लिए।

उदाहरण: क्या वे सभी पहले तर्क (नों) के रूप में एक दस्तावेज / ऑब्जेक्ट / फाइल-पॉइंटर / सीरीज-ऑफ-वैल्यू / निर्देशांक लेते हैं ? भगवान के लिए उन तर्कों के अनुरूप है ।

अपने सहकर्मियों और अपने भविष्य को भ्रमित करने से बचें ।

Comments

"भ्रमित होने से बचें ... आपका भविष्य स्वयं" सामान्य रूप से एक अच्छे दर्शन की तरह लगता है।

— जेने पिंडर

Answer 2

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

चयन फ़नल

1. शब्दार्थ
2. महत्व / प्रासंगिकता
3. उपयोग की आवृत्ति
4. आई / ओ चिंता

1. शब्दार्थ प्रथम

विशेष रूप से ओओपी में, कार्रवाई या संदेश के लिए उनके शब्दार्थिक महत्व के आधार पर पैरामीटर चुनें । एक अच्छी तरह से नामित पैरामीटर के साथ एक अच्छी तरह से नामित विधि का हस्ताक्षर होना चाहिए:

• कॉल करने के लिए स्वाभाविक लग रहा है,
• आशय और व्यवहार के मामले में आत्म-वर्णनात्मक होना।

(इन कारणों से, कभी-कभी आदिम के बजाय कस्टम प्रकार या उपनाम का उपयोग करने से आपके हस्ताक्षर की स्पष्टता बढ़ सकती है।)

2. तब महत्व

सबसे "महत्वपूर्ण" पैरामीटर पहले (या अगले ...) आता है

3. फिर आवृत्ति

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

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

4. आई / ओ को नहीं भूलना चाहिए

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

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

(ध्यान दें कि मैंने वैश्विक चर का उल्लेख नहीं किया है, क्योंकि आप एक, सही का उपयोग क्यों करेंगे?)

---

कुछ बातों पर गौर करें

• प्रयोज्य

  यदि आप ZJR की सलाह का पालन करते हैं तो उपरोक्त में से अधिकांश स्वाभाविक रूप से दिखाई देंगे : इसका उपयोग करें!

• रिफैक्टरिंग पर विचार करें

  यदि आप पैरामीटर ऑर्डर करने के बारे में चिंता करते हैं, तो हो सकता है कि यह चिंता ऊपर की जड़ में और इस तथ्य में पाए कि आपका एपीआई बुरी तरह से डिज़ाइन किया गया है। यदि आपके पास बहुत अधिक पैरामीटर हैं, तो कुछ को संभवतः सबसे अधिक मानकीकृत / संशोधित और परिष्कृत किया जा सकता है ।

• प्रदर्शन पर विचार करें

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

• बेवन के जवाब और क्लीन कोड की सिफारिशों का उल्लेख निश्चित रूप से प्रासंगिक है!

Answer 3

मैं सम्मानपूर्वक प्रस्तुत करना चाहता हूं कि पैरामीटर ऑर्डर के बारे में चिंता करना गलत बात के बारे में चिंता करना है।

अंकल बॉब की पुस्तक " क्लीन कोड " में, वह दृढ़ता से वकालत करते हैं, कि तरीकों में कभी भी दो से अधिक तर्क नहीं होने चाहिए - और अधिकांश में केवल एक ही होना चाहिए, यदि कोई हो। जब यह मामला होता है, तो आदेश स्पष्ट या महत्वहीन होता है।

हालाँकि अपूर्ण रूप से, मैं अंकल बॉब की सलाह का पालन करने की कोशिश कर रहा हूँ - और यह मेरे कोड में सुधार कर रहा है।

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

Comments

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

— केसी पैटन

खांसी PHP खांसी । मुझे खेद है - आप मापदंडों के आदेश के बारे में चिंता न करने के बारे में कुछ कह रहे थे?

— क्रेग

क्या तब आपके पास अपने पैरामीटर ऑब्जेक्ट के लिए एक कंस्ट्रक्टर नहीं होगा जो सिर्फ कई तर्क देता है?

— detly

नहीं - क्योंकि पैरामीटर ऑब्जेक्ट को कई बयानों पर एक तरह से "निर्मित" किया जा सकता है जो अधिक पठनीय है।

— बेवन

@ बेवन: यह अत्यधिक बहस का मुद्दा है। वस्तुओं को इस तरह से बनाने का मतलब है कि वे अब अपरिवर्तनीय नहीं हो सकते; जब भी संभव हो अपनी वस्तुओं को अपरिवर्तनीय बनाए रखना हालांकि स्थिरता बनाए रखने का एक और शानदार तरीका है।

— तदमर्स

Answer 4

मैं IN पैरामीटर को पहले रखने की कोशिश करता हूं, OUT पैरामीटर दूसरा। कुछ प्राकृतिक आदेश भी हैं, उदाहरण के createPoint(double x, double y)लिए दृढ़ता से बेहतर है createPoint(double y, double x)।

Comments

कभी-कभी विपरीत बेहतर होता है, उदाहरण के लिए, जब हमेशा एक ही तर्क होता है और तर्कों में परिवर्तनशील संख्या होती है, जैसे addAllTo(target, something1, something2)।

— माॅर्टिनस

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

— डॉक्टर ब्राउन

@DocBrown आपको वास्तव में अच्छे प्रोग्रामर से बचने की कोशिश नहीं करनी चाहिए, वे उपयोगी हो सकते हैं।

— रायनफेस्कॉटलैंड

@RyanfaeScotland: अरे, मुझे उन्हें पोस्ट करने से पहले दो बार अपनी टिप्पणियों को पढ़ना चाहिए (या कम से कम पांच मिनट के भीतर मैं उन्हें बदल सकता हूं); ;-)

— Doc Brown

Answer 5

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

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

void func1(string param) { }
void func2(string param, int param2) { }
void func3(string param, string param3) { }
void func3(string param, int param2, string param3) { }

Answer 6

आदेश: इनपुट (एस), आउटपुट (एस), वैकल्पिक पैरामीटर।

Answer 7

मैं अक्सर constमापदंडों को पहले रखने के C / C ++ सम्मेलन का पालन करता हूं (जो कि, आपके द्वारा दिए गए मानदंड हैं), और फिर वे जिन्हें आप संदर्भ में पास करते हैं। यह आवश्यक रूप से कॉलिंग फ़ंक्शंस की सही विधि नहीं हो सकती है, लेकिन यदि आप रुचि रखते हैं कि प्रत्येक कंपाइलर मापदंडों को कैसे संभालता है, तो गवर्निंग के नियमों के लिए निम्नलिखित लिंक पर एक नज़र डालें और / या ऑर्डर को पैरामीटर स्टैक पर धकेल दिया जाए।

http://msdn.microsoft.com/en-us/library/zthk2dkh%28v=vs.80%29.aspx

http://en.wikipedia.org/wiki/Calling_convention

Comments

एक और लिंक जिसमें आपकी रुचि हो सकती है, वह है msdn.microsoft.com/en-us/library/984x0h58%28v=vs.71%29.aspx पुनरावर्ती कार्यों के लिए, निम्नलिखित लिंक पर एक नज़र डालें। publications.gbdirect.co.uk/c_book/chapter4/… ऐसा नहीं है कि मैं भूल गया लेकिन, एक नया उपयोगकर्ता होने के नाते मैं एक ऐसी टिप्पणी पोस्ट करने में असमर्थ हूं जिसमें दो से अधिक लिंक हैं .... कितना निराशाजनक!

— बिल

Answer 8

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

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

Comments

"cyprtic": बिंदु बनाने का एक शानदार तरीका।

— बेवन

आपने @Bevan से पहले कभी टाइपो नहीं देखा है?

मेरे पास हर समय टायपोस है - लेखन cyprtic इतना अच्छा था मुझे लगा कि यह उद्देश्य पर था । कृपया इसे वापस बदलें, यह आपकी बात बनाने में मदद करता है, भले ही यह एक दुर्घटना थी।

— बेवन

@ बावन, हाहा ठीक है मैं देख रहा हूँ आप क्या कह रहे हैं। अच्छी बात! इसका बदला हुआ

Answer 9

कभी-कभी (शायद ही कभी), ऐसा लगता है कि एक फ़ंक्शन बनाना जो एक सभ्य मात्रा में पैरामीटर लेता है सबसे अच्छा मार्ग है।

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

हालांकि, जब मैं करता हूं, तो मुझे लगता है कि मैं अक्सर यादृच्छिक पर मापदंडों का क्रम चुन रहा हूं। मैं आमतौर पर "सबसे महत्वपूर्ण पैरामीटर" के साथ पहले "महत्व के क्रम" से जाता हूं।

प्रिंसिपल में आप यादृच्छिक पर चुन रहे हैं । बेशक आप सोच सकते हैं कि पैरामीटर A , पैरामीटर B से अधिक प्रासंगिक है ; लेकिन आपके एपीआई के उपयोगकर्ताओं के लिए ऐसा नहीं हो सकता है, जो सोचते हैं कि बी सबसे प्रासंगिक पैरामीटर है। तो भले ही आप ऑर्डर चुनने में चौकस थे - दूसरों के लिए यह यादृच्छिक लग सकता है ।

क्या ऐसा करने के लिए इससे अच्छा तरीका है? क्या स्पष्टता को बढ़ाने वाले मापदंडों को आदेश देने का एक "सर्वोत्तम अभ्यास" तरीका है?

कई तरीके हैं:

क) तुच्छ मामला: एक से अधिक पैरामीटर का उपयोग न करें।

ख) जैसा कि आपने निर्दिष्ट नहीं किया है कि आपने कौन सी भाषा चुनी है, इस बात की संभावना है कि आपने नामांकित मापदंडों के साथ एक भाषा चुनी है । यह अच्छा सिन्सेटिक शुगर है जो आपको पैरामेट्स के ऑर्डर के महत्व को ढीला करने की अनुमति देता है:fn(name:"John Doe", age:36)

हर भाषा ऐसी बारीकियों की अनुमति नहीं देती है। तो फिर क्या?

ग) आप एक डिक्शनरी के रूप में डिक्शनरी / हैशमैप / एसोसिएटिव एरे का उपयोग कर सकते हैं : उदाहरण के लिए जावास्क्रिप्ट निम्नलिखित की अनुमति देगा: fn({"name":"John Doe", age:36})जो (बी) से बहुत दूर नहीं है।

d) निश्चित रूप से यदि आप जावा जैसी सांख्यिकीय रूप से टाइप की गई भाषा के साथ काम करते हैं । आप एक Hashmap का उपयोग कर सकते हैं , लेकिन आप टाइपिनफॉर्म को ढीला कर सकते हैं (जैसे जब काम कर रहे हों HashMap<String, Object>) जब पैरामीटर अलग-अलग प्रकार के होते हैं (और डालने की आवश्यकता होती है)।

अगला तार्किक कदम Objectउपयुक्त गुणों के साथ एक (यदि आप जावा का उपयोग कर रहे हैं) पास करना होगा या एक संरचना की तरह अधिक हल्का होगा (यदि आप उदाहरण के लिए C # या C / C ++ लिखते हैं)।

अंगूठे का नियम:

1) सबसे अच्छा मामला - आपकी विधि को किसी भी पैरामीटर की आवश्यकता नहीं है

2) अच्छा मामला - आपकी विधि को एक पैरामीटर की आवश्यकता है

3) सहन करने योग्य मामला - आपकी विधि को दो मापदंडों की आवश्यकता है

4) अन्य सभी मामलों को फिर से दर्ज किया जाना चाहिए

Answer 10

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

ज्यादातर चीजों के उदाहरण के लिए आपको पीएचपी के मानक पुस्तकालय प्रलेखन को पढ़ने की कोशिश नहीं करनी चाहिए।

Answer 11

मैं आम तौर पर उन्हें पहले आवश्यकता के साथ आदेश देता हूं, आयात के कुछ संयुक्त माप की तुलना में और किसी "विशिष्ट" के अनुसार उपयोग की आवृत्ति ( ORDER BY required DESC, SOME_MAGIC_FEELING(importancy,frequency)किसी भी विशिष्ट अभ्यास के अनुसार देखा जा सकता है )।

हालाँकि, जैसा कि अन्य ने उल्लेख किया है, मुझे लगता है कि अंतर्निहित समस्या जो इसे एक मुद्दा बनाती है वह बहुत सारे मापदंडों (IMHO, कुछ भी> 3 बहुत अधिक है) का उपयोग कर रही है और यही वास्तविक समस्या है जिसका आपको पता होना चाहिए। वहाँ के बारे में एक दिलचस्प पोस्ट है rebecca murphey के ब्लॉग पर।

मुझे लगता है कि जब आपके पास केवल 1-3 तर्क होते हैं, तो सही क्रम काफी स्पष्ट होता है और आप "सही" महसूस करते हैं।

Answer 12

@Wyatt Barnetts के जवाब के समान, कुछ मापदंडों से अधिक या विधि के लिए बहुत स्पष्ट पैरामीटर, मैं इसके बजाय एक ऑब्जेक्ट पास करने की सलाह दूंगा। यह आम तौर पर अद्यतन करने / बनाए रखने, पढ़ने के लिए स्पष्ट और आदेश देने के बारे में चिंता करने की आवश्यकता को हटा देता है । इसके अलावा, एक विधि के लिए बहुत सारे पैरामीटर एक कोड गंध है और सामान्य रीफैक्टरिंग पैटर्न हैं जो आप इसे सही करने में मदद करने के लिए अनुसरण कर सकते हैं।

स्पष्ट उदाहरण:

public int add(int left, int right)
{
  return left + right;
}

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

हालाँकि, यदि आप कुछ और जटिल जोड़ते हैं:

public SomeComplexReturnValue Calculate(int i, float f, string s, object o)
{
  // do work here
}

बन जाएगा:

public class SomeComplexInputForCalculation
{
  public int i; 
  public float f;
  public string s; 
  public object o;
}

public SomeComplexReturnValue Calculate(SomeComplexInputForCalculation input)
{
  // do work here
}

उम्मीद है की यह मदद करेगा...

Answer 13

इसे इस तरह से क्रमबद्ध करें कि आपको लगता है कि करीने से सबसे ज्यादा फायदा होगा। उदाहरण के लिए, फ़ंक्शन पैरामीटर पहले।

Answer 14

"महत्वपूर्ण पहले" का मतलब पूरी तरह से नहीं है। कुछ सम्मेलन हैं।

यदि आप कॉलिंग ऑब्जेक्ट (अक्सर प्रेषक का नाम) पास करते हैं, तो यह पहले चला जाता है।

सूची में कुछ धाराप्रवाह होना चाहिए , जिसका अर्थ है कि आपको पता होना चाहिए कि जब आप इसे पढ़ते हैं, तो उसके बारे में क्या तर्क होता है। उदाहरण:

CopyFolder (स्ट्रिंग पथ, बूल पुनरावर्ती);

यदि आप पहले पुनरावर्ती डालते हैं, तो यह भ्रामक होगा क्योंकि अभी तक कोई संदर्भ नहीं है। यदि आप पहले से ही अब नकल (1), एक फ़ोल्डर (2) के बारे में हैं, तो तर्क पुनरावर्ती समझ में आने लगता है।

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

तब आप अभी भी पा सकते हैं कि इस संबंध में "समान" तर्क हैं और आदेश के तर्क पर निर्भर होने देने के लिए आपको लुभाया जा सकता है। सिर्फ इसलिए कि एक पंक्ति में दो तार होते हैं और फिर कुछ बूलियंस अच्छे दिखते हैं। किसी स्तर पर यह एक कौशल के बजाय एक कला बन जाएगा।

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