क्या एकल संदर्भ खराब शैली वाली निजी विधियां हैं?

139

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

क्या इस पर आम सहमति है? क्या लंबे सार्वजनिक तरीकों को करना बेहतर है, या उन्हें छोटे टुकड़ों में तोड़ना है, भले ही प्रत्येक टुकड़ा पुन: प्रयोज्य न हो?

coding-style readability

— Jordak
स्रोत

14

संभावित डुप्लिकेट क्या लंबे कार्यों और विधियों को छोटे लोगों में विभाजित करना ठीक है, भले ही उन्हें किसी और चीज से नहीं बुलाया जाएगा?

— gnat

7

सभी उत्तर राय आधारित हैं। मूल लेखक हमेशा सोचते हैं कि उनका रैवियोली कोड अधिक पठनीय है; बाद के संपादकों ने इसे रैवियोली कहा।

— फ्रैंक हिलमैन

5

मेरा सुझाव है कि आप क्लीन कोड पढ़ें। यह इस शैली की सिफारिश करता है और इसके बहुत सारे उदाहरण हैं। यह "कूद के आसपास" समस्या का समाधान भी है।

— कैट

1

मुझे लगता है कि यह आपकी टीम पर निर्भर करता है और कोड की कौन सी लाइनें निहित हैं।

— उम्मीद है कि

1

एकल-उपयोग गेट्टर / सेटर विधियों के आधार पर STRUTS का संपूर्ण ढांचा नहीं है, जो सभी एकल-उपयोग के तरीके हैं?

— ज़िबोबज़

203

नहीं, यह कोई बुरी शैली नहीं है। वास्तव में यह बहुत अच्छी शैली है।

पुन: प्रयोज्य के कारण निजी कार्यों की आवश्यकता नहीं है। यह निश्चित रूप से उन्हें बनाने का एक अच्छा कारण है, लेकिन एक और है: अपघटन।

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

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

जब आप एक बड़ी समस्या को छोटी समस्याओं में बदल देते हैं, भले ही उन छोटी समस्याओं (कार्यों) को केवल एक बार उपयोग / हल किया जाता है, आप कई लाभ प्राप्त करते हैं:

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

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

7

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

— कैंडिड_ओरेंज

14

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

— सुपरकैट

7

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

— मैथ्यू गुइंडन

7

"परीक्षण" बुलेट संदिग्ध आईएमओ है। यदि आपके निजी सदस्य परीक्षण करना चाहते हैं, तो वे संभवतः सार्वजनिक सदस्यों के रूप में, अपनी कक्षा में हैं। दी गई, कक्षा / इंटरफ़ेस को निकालने का पहला कदम एक विधि निकालना है।

— मैथ्यू गुइंडन

6

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

— जुगल

36

यह शायद एक महान विचार है!

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

function step1(){
  // ...
  step2(zarb, foo, biz);
}

function step2(zarb, foo, biz){
  // ...
  step3(zarb, foo, biz, gleep);
}

function step3(zarb, foo, biz, gleep){
  // ...
}

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

हालाँकि , यदि आप एक शुद्ध कार्य में एक या एक से अधिक रेखाएँ निकालने में सफल रहे हैं, जो एक ही, स्पष्ट उद्देश्य ( भले ही केवल एक बार कहा जाता है ) की सेवा करता है, तो आपने पठनीयता में सुधार किया है:

function foo(){
  f = getFrambulation();
  g = deglorbFramb(f);
  r = reglorbulate(g);
}

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

आपको पता चल जाएगा कि जब आप अच्छे क्रिया नामों के साथ कार्य करते हैं, तो आप सही रास्ते पर होते हैं और जब आपका अभिभावक उन्हें कॉल करता है और पूरी बात व्यावहारिक रूप से गद्य के पैराग्राफ की तरह पढ़ता है।

फिर जब आप अधिक कार्यक्षमता जोड़ने के लिए हफ्तों बाद लौटते हैं और आप पाते हैं कि आप वास्तव में उन कार्यों में से एक का उपयोग कर सकते हैं , तो ओह, उत्साहपूर्ण आनंद! क्या चमत्कारिक उज्ज्वल आनंद!

— DaveGauer
स्रोत

2

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

— फ्रैंक हिलमैन

34

@FrankHileman निष्पक्ष होने के लिए, मैंने कभी किसी डेवलपर को उसके या उसके विरोधी के कोड की प्रशंसा करते नहीं देखा।

— टी। सर

4

@ पिछले डेवलपर सभी समस्याओं का स्रोत है!

— फ्रैंक हिलमैन

18

@TSar मैंने पिछले डेवलपर की कभी भी प्रशंसा नहीं की है जब मैं पिछले डेवलपर था।

— IllusiveBrian

3

foo = compose(reglorbulate, deglorbFramb, getFrambulation);

— डीकंपोज़िंग के

19

इसका उत्तर यह है कि यह स्थिति पर निर्भर करता है। @ स्नोमैन बड़े सार्वजनिक समारोह को तोड़ने की सकारात्मकता को शामिल करता है, लेकिन यह याद रखना महत्वपूर्ण है कि नकारात्मक प्रभाव भी हो सकते हैं, जैसा कि आप सही रूप से चिंतित हैं।

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

उनके आंतरिक सामंजस्य और युग्मन के आधार पर अपघटन कार्य, पूर्ण लंबाई नहीं।

— dlasalle
स्रोत

6

पठनीयता को अनदेखा करें, आइए बग रिपोर्टिंग पहलू को देखें: यदि उपयोगकर्ता रिपोर्ट करता है कि बग में हुआ MainMethod(प्राप्त करने के लिए आसान, आमतौर पर प्रतीकों को शामिल किया गया है और आपके पास एक प्रतीक dereference फ़ाइल होनी चाहिए) जो कि 2k लाइनें हैं (लाइन नंबर कभी शामिल नहीं होते हैं बग रिपोर्ट) और यह एक एनआरई है जो उन पंक्तियों में से 1k पर हो सकता है, अगर मैं देख रहा हूं, तो मुझे बहुत नुकसान होगा। लेकिन अगर वे मुझे बताते हैं कि यह हुआ SomeSubMethodAऔर यह 8 लाइनों का था और अपवाद एक एनआरई था, तो मैं शायद इसे ढूंढूंगा और इसे आसानी से ठीक करूंगा।

— ४१०_गोन

2

IMHO, जटिलता को तोड़ने के माध्यम के रूप में शुद्ध रूप से कोड के ब्लॉक को बाहर निकालने का मूल्य, अक्सर जटिलता के बीच के अंतर से संबंधित होगा:

एक पूर्ण और सटीक मानव-भाषा का विवरण जो कोड करता है, जिसमें यह शामिल है कि यह कोने के मामलों को कैसे संभालता है , और
कोड ही।

यदि कोड वर्णन की तुलना में बहुत अधिक जटिल है, तो फ़ंक्शन कॉल के साथ इन-लाइन कोड को बदलने से आसपास के कोड को समझना आसान हो सकता है। दूसरी ओर, कुछ अवधारणाओं को मानव भाषा की तुलना में कंप्यूटर की भाषा में अधिक आसानी से व्यक्त किया जा सकता है। मैं w=x+y+z;, उदाहरण के लिए, की तुलना में अधिक पठनीय होगा w=addThreeNumbersAssumingSumOfFirstTwoDoesntOverflow(x,y,z);।

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

— supercat
स्रोत

2

आपका फ़ंक्शन नाम भ्रामक है। W = x + y + z पर कुछ भी नहीं है जो किसी भी प्रकार के अतिप्रवाह नियंत्रण को इंगित करता है, जबकि विधि नाम से ही अन्यथा प्रतीत होता है। आपके फ़ंक्शन का एक बेहतर नाम "addAll (x, y, z)" होगा, उदाहरण के लिए, या यहां तक कि "Sum (x, y, z)"।

— टी। सर

6

चूंकि निजी तरीकों के बारे में बात कर रहे थे , इसलिए यह सवाल संभवतः सी का जिक्र नहीं है। वैसे भी, मेरी बात नहीं है - आप विधि हस्ताक्षर पर धारणा से निपटने की आवश्यकता के बिना एक ही फ़ंक्शन को "योग" कह सकते हैं। आपके तर्क से, किसी भी पुनरावर्ती विधि को "DoThisAssumingStackDoesntOverflow" कहा जाना चाहिए। वही "FindSubstringAssumingStartingPointIsInsideBounds" के लिए जाता है।

— टी। सारा

1

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

— टी। सारा

1

@TSar: मैं नाम के साथ थोड़ा मुखर हो रहा था, लेकिन मुख्य बात यह है कि (औसत पर स्विच करना क्योंकि यह एक बेहतर उदाहरण है) एक प्रोग्रामर है जो संदर्भ में "(x + y + z + 1) / 3" देखता है यह जानने के लिए कि क्या कॉलिंग कोड दिए गए एवरेज की गणना करने का एक उचित तरीका है, जो किसी की परिभाषा या कॉल साइट को देख रहा है int average3(int n1, int n2, int n3)। "औसत" फ़ंक्शन को विभाजित करने का मतलब होगा कि कोई व्यक्ति जो यह देखना चाहता था कि क्या वह आवश्यकताओं के लिए उपयुक्त है, उसे दो स्थानों पर देखना होगा।

— सुपरकैट

1

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

— टी। सर

2

यह एक संतुलन चुनौती है।

बेहतर है बेहतर

निजी पद्धति प्रभावी रूप से निहित कोड के लिए एक नाम प्रदान करती है , और कभी-कभी एक सार्थक हस्ताक्षर (जब तक कि इसके आधे पैरामीटर पूरी तरह से अस्पष्ट, अनिर्धारित अंतर्निर्भरता के साथ तदर्थ डेटा नहीं हैं)।

कोड निर्माण को नाम देना आम तौर पर अच्छा होता है, जब तक कि नाम कॉलर के लिए एक सार्थक अनुबंध का सुझाव देते हैं , और निजी विधि का अनुबंध सटीक रूप से मेल खाता है जो नाम का सुझाव देता है।

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

बाद में रखरखाव में मदद की जाती है, भी, क्योंकि अतिरिक्त नामकरण कोड को स्व-दस्तावेजीकरण बनाने में मदद करता है ।

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

जब तक यह ठीक नहीं हो जाता

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

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

— जिरका हनिका
स्रोत

1

दूसरों ने जो कहा है, उसके विपरीत, मैं यह तर्क दूंगा कि एक लंबी सार्वजनिक पद्धति एक डिजाइन गंध है जिसे निजी तरीकों में विघटित करके ठीक नहीं किया जाता है।

लेकिन कभी-कभी मेरे पास एक बड़ी सार्वजनिक विधि होती है जिसे छोटे चरणों में तोड़ा जा सकता है

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

निजी तरीकों में विघटित क्यों नहीं? यहाँ कुछ कारण हैं:

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

लेकिन मुझे इस बात की चिंता है कि जो भी व्यक्ति अलग-अलग निजी तरीकों से कूदने की विधि पढ़ता है, उसे पढ़ने की क्षमता को नुकसान होगा

यह एक तर्क है जो मैंने हाल ही में अपने एक सहकर्मी के साथ किया है। उनका तर्क है कि एक ही फाइल / विधि में एक मॉड्यूल का संपूर्ण व्यवहार होने से पठनीयता में सुधार होता है। मैं मानता हूं कि कोड का पालन करना आसान है जब सभी एक साथ होते हैं, लेकिन कोड कम आसान होता है क्योंकि जटिलता बढ़ती है। जैसे-जैसे एक प्रणाली बढ़ती है, यह पूरे मॉड्यूल के बारे में एक पूरे के रूप में तर्क करने योग्य हो जाता है। जब आप एक ही जिम्मेदारी के साथ कई वर्गों में जटिल तर्क का विघटन करते हैं, तो प्रत्येक भाग के बारे में तर्क करना बहुत आसान हो जाता है।

— शमूएल
स्रोत

1

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

— 17

1

मैं समझता हूँ कि आप कहाँ से आ रहे हैं, लेकिन मैं कोड बदबू आ रही है की तरह एक ओपी संकेत कर रहे हैं के बारे में पूछ रहा है कि यह लगता है कि है एक बेहतर डिजाइन के लिए तैयार है। इससे पहले कि आप उस समस्या में भाग लें, समय से पहले गर्भपात इन इंटरफेस को डिजाइन करेगा।

— शमूएल

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

— इटरनल