🤾🏻 🈹 💅🏿 ऑब्जेक्ट जिमनास्टिक 🤽 👨‍👨‍👦‍👦 🧛

^{मूल पाठ के पहले दो पैराग्राफ में, लेखक बताता है कि उसने दोस्तों के साथ बीयर कैसे पिया।} ^{मैंने उन्हें बचपन की जिमनास्टिक के बारे में शुक्रवार की तस्वीर के साथ बदल दिया।}

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

ये नियम आपके कोड की पठनीयता, परीक्षणशीलता, समझदारी और स्थिरता पर ध्यान केंद्रित करते हैं। यदि आप पहले से ही कोड लिख रहे हैं जिसे हम पढ़ते हैं, परीक्षण करते हैं, समझते हैं और समर्थन करते हैं, तो ये नियम इसे अधिक पठनीय, परीक्षण योग्य बनाने में मदद करेंगे। स्पष्ट और समर्थित।

नीचे मैं इन 9 नियमों पर टिप्पणी करूंगा:

एक विधि में केवल एक स्तर का इंडेंटेशन
एल्स का उपयोग न करें
सभी आदिम प्रकार और तार लपेटें
प्रथम श्रेणी संग्रह
प्रति पंक्ति एक डॉट
संक्षिप्तीकरण का उपयोग न करें
एंटिटीज को छोटा रखें
2 से अधिक विशेषताओं वाला कोई वर्ग नहीं
कोई गेटर्स, सेटर या प्रॉपर्टी नहीं

1. एक विधि में केवल एक स्तर का इंडेंटेशन

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

class Board { public String board() { StringBuilder buf = new StringBuilder(); // 0 for (int i = 0; i < 10; i++) { // 1 for (int j = 0; j < 10; j++) { // 2 buf.append(data[i][j]); } buf.append("\n"); } return buf.toString(); } }

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

आपके पास कम लाइनें नहीं होंगी, लेकिन आप उनकी पठनीयता में काफी सुधार करेंगे:

 class Board { public String board() { StringBuilder buf = new StringBuilder(); collectRows(buf); return buf.toString(); } private void collectRows(StringBuilder buf) { for (int i = 0; i < 10; i++) { collectRow(buf, i); } } private void collectRow(StringBuilder buf, int row) { for (int i = 0; i < 10; i++) { buf.append(data[row][i]); } buf.append("\n"); } }

2. एल्स का उपयोग न करें

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

 public void login(String username, String password) { if (userRepository.isValid(username, password)) { redirect('homepage'); } else { addFlash('error', 'Bad credentials'); redirect('login'); } }

बस एक और रास्ता निकालने के लिए जल्दी वापसी पर भरोसा करना है।

 public void login(String username, String password) { if (userRepository.isValid(username, password)) { return redirect('homepage'); } addFlash('error', 'Bad credentials'); return redirect('login'); }

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

एक विकल्प आपके रिटर्न पैरामीट्रिक बनाने के लिए एक चर का परिचय दे सकता है। हालांकि उत्तरार्द्ध हमेशा संभव नहीं होता है।

 public void login(String username, String password) { String redirectRoute = 'homepage'; if (!userRepository.isValid(username, password)) { addFlash('error', 'Bad credentials'); redirectRoute = 'login'; } redirect(redirectRoute); }

यह भी याद किया जाना चाहिए कि ओओपी हमें शक्तिशाली क्षमता प्रदान करता है, जैसे कि बहुरूपता । अशक्त वस्तु , स्थिति और रणनीति पैटर्न भी आपकी सहायता कर सकते हैं।

उदाहरण के लिए, स्थिति के आधार पर कार्रवाई का निर्धारण करने के लिए if/else का उपयोग करने के बजाय (उदाहरण के लिए, रनिंग, WAITING, आदि), राज्य पैटर्न को वरीयता देते हैं, क्योंकि इसका उपयोग राज्य वस्तु के आधार पर विभिन्न व्यवहार को एनकैप करने के लिए किया जाता है।

^{स्रोत: sourcemaking.com/design_patterns/state}

3. सभी आदिम प्रकारों और तारों को लपेटें

इस नियम का पालन करना बहुत आसान है, आपको सिर्फ प्राइमर (आदिम जुनून) के साथ जुनून के विरोधी पैटर्न से बचने के लिए सभी प्राइमरी को ऑब्जेक्ट्स में एनक्रिप्ट करना होगा।

यदि आपके आदिम प्रकार के एक चर का व्यवहार होता है, तो आपको उसे एनकोड करना होगा। और यह विशेष रूप से Domain Driven Design के लिए सच है। डीडीडी मूल्य वस्तुओं का वर्णन करता है, उदाहरण के लिए: धन, घड़ी।

4. प्रथम श्रेणी संग्रह

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

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

5. प्रति पंक्ति एक डॉट

एक बिंदु वह है जिसे आप जावा या सी # में कॉल करने के तरीकों का उपयोग करते हैं। PHP में, यह एक तीर होगा।

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

अन्य वर्गों के लिए, आपको इस नियम का पालन करना होगा। यह Demeter के कानून का प्रत्यक्ष परिणाम है, जिसमें केवल प्रत्यक्ष मित्रों की आवश्यकता होती है और अजनबियों से संपर्क नहीं होता है:

इन वर्गों पर एक नज़र डालें:

 class Location { public Piece current; }

 class Piece { public String representation; }

 class Board { public String boardRepresentation() { StringBuilder buf = new StringBuilder(); for (Location loc : squares()) { buf.append(loc.current.representation.substring(0, 1)); } return buf.toString(); } }

Piece और Location वर्गों में सार्वजनिक गुण होना ठीक है। वास्तव में, एक सार्वजनिक विशेषता और बसने / पाने वालों के साथ एक निजी एक ही बात है (नियम 9 देखें)।

हालाँकि, boardRepresentation() विधि बहुत ही भयानक है। इसकी पहली पंक्ति पर एक नज़र डालें:

 buf.append(loc.current.representation.substring(0, 1));

विधि Location लेता है, फिर उसका वर्तमान Piece , फिर Piece प्रतिनिधित्व, जिसके साथ वह क्रिया करता है। यह प्रति पंक्ति एक बिंदु से बहुत दूर है।

सौभाग्य से, Demeter का नियम आपको केवल अपने दोस्तों से संपर्क करने के लिए कहता है। चलो इसे करते हैं:

 class Location { private Piece current; public void addTo(StringBuilder buf) { current.addTo(buf); } }

Piece उदाहरण को निजी बनाकर, आप यह सुनिश्चित करते हैं कि आप कुछ भी बुरा करने की कोशिश नहीं करेंगे। हालाँकि, चूंकि आपको इस विशेषता के साथ कार्रवाई करने की आवश्यकता है, इसलिए आपको एक नया addTo() विधि जोड़ने की आवश्यकता है। यह टुकड़ा वर्ग को जोड़ने के लिए Location वर्ग की जिम्मेदारी नहीं है, इसलिए आपको उससे पूछने की आवश्यकता है:

 class Piece { private String representation; public String character() { return representation.substring(0, 1); } public void addTo(StringBuilder buf) { buf.append(character()); } }

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

इसके अलावा, एक नई विधि में पहला चरित्र representation प्राप्त करने के लिए कोड को उजागर करना एक अच्छा विचार जैसा लगता है, क्योंकि इसका उपयोग किसी बिंदु पर किया जा सकता है। अंत में, अद्यतन बोर्ड वर्ग कोड:

 class Board { public String boardRepresentation() { StringBuilder buf = new StringBuilder(); for (Location location : squares()) { location.addTo(buf); } return buf.toString(); } }

बहुत बेहतर, सही?

6. संक्षिप्तीकरण का उपयोग न करें

सही सवाल है, आपको संक्षिप्ताक्षरों का उपयोग करने की आवश्यकता क्यों है?

आप जवाब दे सकते हैं कि ऐसा इसलिए है क्योंकि आप एक ही नाम बार-बार लिखते हैं। और मैं जवाब दूंगा, अगर इस विधि का उपयोग कई बार किया जाता है, तो यह कोड के दोहराव जैसा दिखता है ।

आप कह सकते हैं कि विधि का नाम वैसे भी बहुत लंबा है। तब मैं आपको बताऊंगा कि शायद इस वर्ग के पास बहुत अधिक जिम्मेदारियां हैं, और यह बुरा है, क्योंकि यह एकमात्र कर्तव्य के सिद्धांत का उल्लंघन करता है।

मैं अक्सर कहता हूं कि यदि आप एक वर्ग या विधि के लिए एक उपयुक्त नाम नहीं खोज सकते हैं, तो कुछ गलत है। मैं इस नियम का उपयोग करता हूं जब मैं नाम के माध्यम से विकास का पालन करता हूं।

काटो मत, इशारा करो।

7. एंटिटीज को छोटा रखें

एक वर्ग 50 से अधिक लाइनें नहीं है और एक पैकेज 10 से अधिक फाइलें नहीं है। वैसे यह आपके ऊपर है, लेकिन मुझे लगता है कि आप इस संख्या को 50 से बढ़ाकर 150 कर सकते हैं।

इस नियम के पीछे विचार यह है कि लंबी फ़ाइलों को पढ़ना कठिन, समझने में कठिन और बनाए रखने के लिए कठिन है।

8. 2 से अधिक विशेषताओं वाला कोई वर्ग नहीं

मुझे लगा कि जब मैं इस नियम के बारे में बात करूंगा तो लोग हंसेंगे, लेकिन ऐसा नहीं हुआ। यह नियम शायद सबसे जटिल है, लेकिन यह उच्च कनेक्टिविटी और बेहतर एनकैप्सुलेशन में योगदान देता है।

एक तस्वीर एक हजार शब्दों के लायक है, इसलिए यहां चित्र में इस नियम की व्याख्या है। कृपया ध्यान दें कि यह तीसरे नियम पर आधारित है।

^{स्रोत: github.com/TheLadders/object-calisthenics#rule-8-no-classes-with-more-than-two-instance-variables}

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

9. कोई गेटर्स, सेटर और प्रॉपर्टी नहीं

मेरा पसंदीदा नियम। यह संकेत के रूप में कहा जा सकता है , बजाय पूछा ।

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

यही कारण है कि गर्टर्स / सेटर को बुराई माना जाता है । और फिर, वे खुलेपन / निकटता के सिद्धांत का उल्लंघन करते हैं।

उदाहरण के लिए:

 // Game private int score; public void setScore(int score) { this.score = score; } public int getScore() { return score; } // Usage game.setScore(game.getScore() + ENEMY_DESTROYED_SCORE);

ऊपर दिए गए कोड में, getScore() उपयोग निर्णय लेने के लिए किया जाता है। आप यह तय करते हैं कि Game क्लास के लिए इस जिम्मेदारी को छोड़ने के बजाय, अपने score को कैसे बढ़ाया जाए।

सबसे अच्छा उपाय यह है कि गेटर्स और सेटर को हटा दिया जाए और उन तरीकों को प्रदान किया जाए जो समझ में आते हैं। याद रखें, आप कक्षा को यह बताने के बजाय कि उसे क्या करना है। नीचे, आप अपने स्कोर को अपडेट करने के लिए कक्षा को बताते हैं, क्योंकि आपने ENEMY_DESTROYED_SCORE दुश्मनों को नष्ट कर दिया है।

 // Game public void addScore(int delta) { score += delta; } // Usage game.addScore(ENEMY_DESTROYED_SCORE);

यह गेम क्लास के लिए जिम्मेदार है कि स्कोर कैसे अपडेट किया जाए।

इस स्थिति में, आप getScore() छोड़ सकते हैं क्योंकि आप इसे उपयोगकर्ता इंटरफ़ेस में कहीं प्रदर्शित करना चाहते हैं, लेकिन याद रखें कि बसने की अनुमति नहीं है ।

निष्कर्ष

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

ऑब्जेक्ट जिमनास्टिक