मेरी कक्षाओं और विधियों को यथासंभव छोटा रखें?

Question

कुछ दिन पहले, मैं एक सॉफ्टवेयर इंजीनियरिंग पीएचडी उम्मीदवार से बात कर रहा था और कुछ बिंदु पर उसने मुझसे कहा:

अपनी कक्षाओं और विधियों को यथासंभव छोटा रखें

और मुझे आश्चर्य है कि क्या यह हमेशा एक अच्छा अभ्यास है।

उदाहरण के लिए मेरा मतलब यह है कि क्या इसमें केवल 2 अभ्यागत के साथ एक वर्ग होना योग्य है? उदाहरण के लिए, कुछ तरीकों से मुझे काम करने के लिए पूर्णांकों के जोड़े की आवश्यकता होती है। क्या मुझे "PairOfIntgers" क्लास लिखना चाहिए?

क्या सोचने का यह तरीका बहुत सारे टुकड़ों में कोड को "तोड़" सकता है?

Comments

यह होना चाहिए"As small as possible, but no smaller."

— स्टुपरयूसर

"मैं उदाहरण के लिए इसका मतलब है, क्या इसमें केवल 2 एटिब्यूट्स के साथ एक क्लास होना योग्य है?" - यह हो सकता है "आदिम ओबसेशन" के लिए खोज (जैसे jamesshore.com/Blog/PrimitiveObsession.html )

— टॉरस्टेन

मुझे लगता है कि भ्रम का स्रोत "संभव" शब्द है। सिद्धांत संभव हो जाता है यदि "संभव" केवल कोड का संदर्भ दे रहा है, क्योंकि सबसे छोटा संभव वर्ग जो कुछ भी उपयोगी होता है उसकी केवल एक विधि होती है (और कुछ मामलों में शून्य)। उम्मीदवार बहुत संभावना है कि सामंजस्य और युग्मन को ध्यान में रखे।

— केल्विन

Answer 1

उस सलाह में सच्चाई का एक दाना है, लेकिन IMHO यह बहुत अच्छी तरह से व्यक्त नहीं किया गया है, इस प्रकार गलतफहमी और / या एक बेवकूफ चरम पर ले जाना आसान है। किसी भी दर पर, यह कठोर कानून के बजाय अंगूठे का नियम होना चाहिए। और आपको इस तरह के नियमों का हमेशा "उचित सीमा के भीतर" , या "" लागू करना चाहिए , लेकिन अपने सामान्य ज्ञान का उपयोग करना न भूलें ... :-)

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

Comments

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

— रियाथल

अंगूठे का मेरा व्यक्तिगत नियम है: यदि आप एक बार में स्क्रीन पर एक संपूर्ण विधि कार्यान्वयन को नहीं देख सकते हैं, तो रिफैक्टर।

— दान रे

@DanRay, हाँ, मैं एक ही नियम रखता था, जब तक कि मैं क्लीन कोड नहीं पढ़ता । यह काफी झटका था, लेकिन धीरे-धीरे मेरे इष्टतम को लगभग 10 लाइनों के नीचे जाने का कारण बना।

— पेटर टॉर्क

IMO क्लीन कोड छोटे तरीकों के प्रति अपने चरम में भयानक है। समस्या यह है कि जब तरीकों को छोटा किया जाता है, तो उनमें से अधिक होगा। बेशक बहुत लंबी विधियां बहुत लंबी हैं, लेकिन बॉब मार्टिन 1 10-लाइन एक पर 10 1-लाइन विधियों को पसंद करते हैं (इस प्रकार प्रभावी रूप से समान कोड लगभग 5x जितना स्क्रीन स्पेस लेते हैं)। हो सकता है कि यह किसी प्रकार की शैक्षिक चाल हो, मुझे विश्वास नहीं हो रहा है कि वास्तव में कोई सोचता है कि उस पुस्तक का कोड कोई अच्छा है।

— जूनास पुलकका

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

— डेविड हरकनेस

Answer 2

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

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

इस मामले में एक कक्षा बनाने के लिए एक और सकारात्मक बात यह है कि कक्षा एक बेहतर स्तर / अच्छे को विकसित कर सकती है, जैसा कि मानचित्र या सूची की तरह निचले स्तर की डेटा संरचना कह सकते हैं।

तीसरा, एक अच्छा अमूर्त पठनीयता में काफी सुधार ला सकता है। एसआरपी का पालन करने वाली कक्षाएं आमतौर पर उन वर्गों की तुलना में मानव द्वारा समझने में बहुत आसान होती हैं जो नहीं करते हैं।

और बस एक अंतिम नोट के रूप में ... कोई फर्क नहीं पड़ता कि आप कितने अच्छे छात्र हैं ... ओओपी और अच्छे अमूर्त को समझने के लिए और उनका उपयोग करने के लिए, आपको अनुभव की आवश्यकता है। आपको खराब कोड लिखने और इसे बनाए रखने के लिए दर्द से गुजरना होगा। आपको यह देखने की आवश्यकता है कि 'अच्छा' क्या है और लाइन के नीचे क्या समस्या होगी, इसके बारे में अपने ज्ञान का निर्माण करने के लिए दूसरों को अच्छा कोड लिखना होगा ... इसलिए यदि आप अभी इसे प्राप्त नहीं करते हैं, तो अपने आप को हरा न दें।

Answer 3

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

Answer 4

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

आपको कक्षाओं को छोटा रखने की कोशिश करें। और तरीके भी छोटे। शायद 10 लाइनें? वर्तमान में मैं प्रवाह डिजाइन और घटना आधारित घटकों का उपयोग करने की कोशिश कर रहा हूं जो कक्षाओं को छोटा रखने में मदद करता है। पहले मैं कई कक्षाओं के लिए चिंतित था लेकिन यह वास्तव में काम करता है !!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/03 /20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx

Answer 5

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

केवल "वर्गों और विधियों को यथासंभव छोटा करें", मेरी राय में, गुमराह है। असली चुनौती है, जैसा कि @c_maker बताते हैं, अच्छा सार प्रदान करने के लिए। एक साथ दो संख्याओं को समूहीकृत करने का आपका उदाहरण बहुत अच्छा है, उदाहरण के लिए, यदि आप जटिल संख्या अंकगणितीय के कार्यान्वयन पर काम कर रहे हैं, या यदि एक यूनिक्स प्रणाली पर आपको उपयोगकर्ता / समूह के संदर्भ को संदर्भित करने की आवश्यकता है। यह बहुत कम समझ में आता है अगर संख्या उस चालान का प्रतिनिधित्व करती है, कहते हैं, एक चालान आईडी और एक उत्पाद आईडी।

Answer 6

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

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

यहां एक अच्छा उदाहरण है: आपके पास एक लूप है, और आपके पास उस पद्धति में कोड की शायद 60 लाइनें हैं। उस मामले में, यह शायद रिफ्लेक्टर का समय है क्योंकि आप उस पद्धति में बहुत अधिक कर रहे हैं।

लेकिन, यह एक कठिन और तेज़ नियम नहीं है। यह केवल कुछ ऐसा है जिसे आप करके सीखते हैं। और, अन्य डेवलपर्स जो आप मेरे साथ काम कर रहे हैं वे हमेशा सहमत नहीं होते हैं और आपको एक कोड समीक्षा या जो भी हो, में बुला सकते हैं।

Comments

एसआरपी का पालन करने के बजाय कभी भी छोटा न करें और यह स्वचालित रूप से काम करेगा।

— विनय प्रजापति

Answer 7

अंकल बॉब का कहना है कि आपको अपने तरीकों को सुधारना / विभाजित करना / निकालना चाहिए जब तक कि उन्हें छोटा करना असंभव न हो । यह आमतौर पर प्रत्येक 3 या 4 लाइनों के साथ कई तरीके होने में समाप्त होता है। जब आप बहुत अधिक विधियाँ प्राप्त करते हैं, तो आपको और कक्षाएं बनानी होंगी।

यदि आप एसआरपी और प्रति स्तर अमूर्त स्तर का पालन करने की कोशिश करते हैं, तो ये नियम आपकी अच्छी सेवा करते हैं। कम से कम वे मेरी अच्छी सेवा करते हैं। "जितना संभव हो उतना छोटा" के लिए लक्ष्य करना मुझे उचित छोटे तरीके देता है, क्योंकि मैं आमतौर पर लक्ष्य को कम करता हूं।

और छोटी कक्षाओं को समझना हमेशा आसान होता है। आगे बढ़ें, "क्लीन कोड" पढ़ें