प्रागितिहास

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

एसआरपी मायने रखती है

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

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

और ये सभी संकेत एक साथ चलते हैं, ये एक ही कोड के संकेत हैं। आपको उदाहरण के लिए, अच्छी तरह से परीक्षण किए गए कोड और अच्छी तरह से संरचित कोड के बीच चयन करने की आवश्यकता नहीं है।

मौजूदा परिभाषाएं काम नहीं करती हैं

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

दूसरी, अधिक प्रत्यक्ष परिभाषा है: "कोड में केवल एक जिम्मेदारी होनी चाहिए।" इस परिभाषा के साथ समस्या यह है कि सब कुछ सामान्य करना मानव स्वभाव है।

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

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

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

कुल मिलाकर, यदि एसआरपी सिद्धांत को संतुष्ट करने के लिए किसी प्रकार का कोड लगता है, लेकिन एक ही समय में यह अप्रिय लगता है - पता है कि ऐसा क्यों होता है। क्योंकि "कोड की परिभाषा में एक जिम्मेदारी होनी चाहिए" बस काम नहीं करता है।

अधिक उपयुक्त परिभाषा

परीक्षण और त्रुटि से, मेरी एक बेहतर परिभाषा थी:
कोड जिम्मेदारी बहुत बड़ी नहीं होनी चाहिए

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

लेकिन इसे कैसे मापा जाए, यह कैसे निर्धारित किया जाए कि इस कोड की जिम्मेदारी बहुत बड़ी है?

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

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

कुछ बिंदु:

बेशक, जैसा कि मैंने पहले ही उल्लेख किया है, सिक्के का एक फ्लिप पक्ष है, और एक पंक्ति में 800 विधियां 800 लाइनों पर एक विधि से बेहतर नहीं हो सकती हैं, हर चीज में संतुलन होना चाहिए।

दूसरा - मैं इस सवाल को कवर नहीं करता हूं कि इस या उस कोड को उसकी जिम्मेदारी के अनुसार कहां रखा जाए। उदाहरण के लिए, कभी-कभी डेवलपर्स को DAL परत में बहुत अधिक तर्क खींचने में भी कठिनाई होती है।

तीसरा, मैं किसी भी विशिष्ट कठिन सीमा का प्रस्ताव नहीं करता हूं, जैसे "प्रति फ़ंक्शन 50 से अधिक लाइनें"। इस दृष्टिकोण में केवल डेवलपर्स के विकास के लिए एक दिशा शामिल है, और शायद टीमें। वह मेरे लिए काम करता है, उसे दूसरों के लिए पैसा कमाना चाहिए।

और अंत में, यदि आप टीडीडी के माध्यम से जाते हैं, तो यह अकेले निश्चित रूप से कोड को लंबे समय तक विघटित करेगा, इससे पहले कि आप उन 20 परीक्षणों को प्रत्येक के साथ 20 बार लिखें।

बॉयलरप्लेट कोड से व्यावसायिक तर्क को अलग करना

अच्छे कोड के नियमों के बारे में बात करते हुए, आप उदाहरण के बिना नहीं कर सकते। पहला उदाहरण बॉयलरप्लेट कोड को अलग करने के बारे में है।

यह उदाहरण दर्शाता है कि आमतौर पर बैक-एंड कोड कैसे लिखा जाता है। लोग आमतौर पर वेब सर्वर एक्सप्रेस जैसे URL, अनुरोध विधि, आदि के मापदंडों को इंगित करने वाले कोड के साथ तार्किक रूप से लिखते हैं।

मैंने व्यापार तर्क को हरे मार्कर के रूप में चिह्नित किया, और लाल प्रतिच्छेदित कोड जो क्वेरी पैरामीटर (लाल) के साथ बातचीत करता है।

मैं हमेशा इन दो जिम्मेदारियों को इस तरह साझा करता हूं:

इस उदाहरण में, एक्सप्रेस के साथ सभी इंटरैक्शन एक अलग फ़ाइल में है।

पहली नज़र में, ऐसा लग सकता है कि दूसरा उदाहरण सुधार नहीं लाया, एक के बजाय 2 फाइलें थीं, अतिरिक्त लाइनें दिखाई दीं, जो पहले अस्तित्व में नहीं थीं - वर्ग का नाम और विधि हस्ताक्षर। और फिर यह कोड का पृथक्करण क्या देता है? सबसे पहले, "आवेदन प्रविष्टि बिंदु" अब एक्सप्रेस नहीं है। अब यह एक नियमित टाइपस्क्रिप्ट फ़ंक्शन है। या एक जावास्क्रिप्ट फ़ंक्शन, क्या सी #, जो किस पर WebAPI लिखता है।

यह बदले में, आपको विभिन्न कार्यों को करने की अनुमति देता है जो पहले उदाहरण में उपलब्ध नहीं हैं। उदाहरण के लिए, आप एक्सप्रेस को बढ़ाए बिना व्यवहार परीक्षण लिख सकते हैं, परीक्षण के अंदर http अनुरोधों का उपयोग किए बिना। और यहां तक कि किसी भी प्रकार के गीला करने की आवश्यकता नहीं है, राउटर ऑब्जेक्ट को अपने "परीक्षण" ऑब्जेक्ट से बदल दें, अब आवेदन कोड को सीधे परीक्षण से सीधे बुलाया जा सकता है।

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

फूट डालो और जीतो

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

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

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

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

async function sendEmployeeReportToProvider(reportId){ const data = await dal.getEmployeeReportData(reportId); const formatted = reportDataService.prepareEmployeeReport(data); await networkService.sendReport(formatted); }

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

अगला, हम आवश्यकताओं पर लौटते हैं और यह पता लगाते हैं कि रिपोर्ट में वेतन अनुभाग और काम के घंटों के साथ एक खंड शामिल होना चाहिए।

 function prepareEmployeeReport(reportData){ const salarySection = prepareSalarySection(reportData); const workHoursSection = prepareWorkHoursSection(reportData); return { salarySection, workHoursSection }; }

और इसी तरह हम छोटे-छोटे तरीकों को लागू करना चाहते हैं, जो तुच्छ अवशेषों के करीब हैं।

ओपन-क्लोज प्रिंसिपल के साथ बातचीत

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

 async function serveEmployeeReportToProvider(reportId, serveMethod){ /* lots of code to read and convert the report */ switch(serveMethod) { case sendToProvider: /* implementation of sending */ case print: /* implementation of printing */ default: throw; } }

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

और कैसे विभाजित और जीत विधि एक ही समस्या को हल करती है:

 async function printEmployeeReport(reportId){ const data = await dal.getEmployeeReportData(reportId); const formatted = reportDataService.prepareEmployeeReport(data); await printService.printReport(formatted); }

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

विकल्प

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

कुल मिलाकर

सिद्धांत का पालन करने में, आप लाभ पा सकते हैं।

"एक जिम्मेदारी होनी चाहिए" की परिभाषा काम नहीं करती है।

एक बेहतर परिभाषा और कई अप्रत्यक्ष विशेषताएं हैं, तथाकथित कोड बदबू आने की आवश्यकता को इंगित करता है।

"विभाजित और जीत" दृष्टिकोण आपको तुरंत अच्छी तरह से संरचित और स्व-दस्तावेजीकरण कोड लिखने की अनुमति देता है।

एकमात्र जिम्मेदारी का कठिन सिद्धांत