2009-06-10 12 views
43

डिजाइन पैटर्न वास्तव में कितने महत्वपूर्ण हैं?डिजाइन पैटर्न वास्तव में कितने महत्वपूर्ण हैं?

मुझे लगता है कि प्रोग्रामर की पिछली पीढ़ी ने डिजाइन पैटर्न का उपयोग नहीं किया था (जो लोग 80 के दशक में और 90 के दशक के मध्य से स्नातक थे)। क्या हाल के स्नातक इसे सामान्य रूप से जानते हैं और इसे और अधिक उपयोग करते हैं?

आप रुचि रखते हैं, मैं भी एक Survery बना दिया है और आप उसे यहां देख सकते हैं:

http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d

अद्यतन:

http://img192.imageshack.us/img192/7107/surveyresults.png

+6

क्या आप अपने सर्वेक्षण के परिणाम पोस्ट कर सकते हैं? मुझे परिणाम –

+3

में दिलचस्पी है, "डिजाइन-पैटर्न" टैग को ध्यान में रखते हुए SO पर लगभग 1000 प्रश्नों का उपयोग किया गया है, मुझे लगता है कि अकेले ही आपके प्रश्न का उत्तर दे सकता है ... या कम से कम उन प्रश्नों में से एक का जवाब है। – gnovice

+1

@ क्वांग यकीन है कि मैं कुछ परिणाम पोस्ट करूंगा। क्या परिणाम भी खोलने का कोई तरीका है? यदि संभव हो तो मैं इसे खोलना चाहता हूं। –

उत्तर

90

हमने 80 के दशक में डिजाइन पैटर्न का उपयोग किया, हम अभी नहीं जानते थे कि वे डिजाइन पैटर्न थे।

57

: यहाँ प्रारंभिक सर्वेक्षण के परिणाम हैं मेरी राय में डिजाइन पैटर्न का सबसे बड़ा लाभ यह है कि यह डेवलपर्स को सॉफ़्टवेयर समाधानों के बारे में बात करने के लिए एक सामान्य शब्दावली देता है।

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

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

बहुत महत्वपूर्ण है। सॉफ्टवेयर उनके बिना बनाया जा सकता है, लेकिन यह निश्चित रूप से बहुत कठिन है।

+11

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

+18

लेकिन क्या आप खुश नहीं हैं कि आप लोगों को कुछ तरीकों से सिंगलटन पैटर्न का उपयोग न करने के लिए कह सकते हैं, और वे जानते हैं कि आप किस बारे में बात कर रहे हैं। –

+3

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

38

उन्हें बिल्कुल जरूरी नहीं है, लेकिन अच्छा निश्चित रूप से खराब से अधिक है।

अच्छा:

  1. कोड पठनीयता: वे मदद करते हैं आप आप क्या हासिल करने की कोशिश कर रहे हैं के लिए बेहतर नाम के साथ अधिक से समझा जा सकता कोड लिखें।
    • कोड रखरखाव: आपके कोड को बनाए रखने की अनुमति देता है क्योंकि यह अधिक समझ में आता है।
    • संचार: वे प्रोग्रामर के बीच डिजाइन लक्ष्यों को संवाद करने में आपकी सहायता करते हैं।
    • इरादा: वे कोड को सीखने वाले व्यक्ति को तुरंत आपके कोड का इरादा दिखाते हैं।
    • कोड पुन: उपयोग: वे आम समस्याओं के सामान्य समाधान की पहचान करने में आपकी सहायता करते हैं।
    • कम कोड: वे आपको कम कोड लिखने की अनुमति देते हैं क्योंकि आपका अधिक कोड सामान्य आधार वर्गों से सामान्य कार्यक्षमता प्राप्त कर सकता है।
    • परीक्षण और ध्वनि समाधान: अधिकांश डिज़ाइन पैटर्न का परीक्षण, सिद्ध और ध्वनि परीक्षण किया जाता है।

बुरा:

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

मैं पूरी तरह से सहमत हूं, लेकिन आपकी आलोचना (1) डिज़ाइन पैटर्न अवधारणा के बजाय विशिष्ट पैटर्न पर लागू होती प्रतीत होती है। Altho सबसे आम डिजाइन पैटर्न संकेत के स्तर पर आधारित हैं। –

+1

जब आप 'सिंगलटन' जोड़ते थे तो मुझे हंसना पड़ता था। यह कई सालों से मेरे पक्ष में कांटा रहा है !!! –

+1

:) मैंने इसे अधिकतर विनोद के लिए जोड़ा, लेकिन वैश्विक स्थिति और स्वयं को केवल कुछ में सीमित करने के लिए एक अच्छी बात नहीं है। –

7

महत्वपूर्ण शब्द है कि मैं का प्रयोग करेंगे नहीं है। मैं "सहायक" शब्द का उपयोग करूंगा। डेवलपर्स को लगातार समस्याओं/समाधानों का वर्णन करने के लिए एक आम भाषा देना उपयोगी है - एक सहयोगी वातावरण में मोरेसो।

2

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

7

मुझे लगता है कि आप एक डिजाइन पैटर्न क्या है इस बिंदु पर चूक जाते हैं।

सॉफ़्टवेयर इंजीनियरिंग में, एक डिज़ाइन पैटर्न सॉफ़्टवेयर डिज़ाइन में सामान्य रूप से होने वाली समस्या का एक सामान्य पुन: प्रयोज्य समाधान है।

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

मुझे लगता है कि डिजाइन पैटर्न महत्वपूर्ण हैं क्योंकि वे यदि आप उन क्षेत्रों डिजाइन पैटर्न पर लागू होते हैं में समस्याओं को हल करने आदेश तरीके सिखाने।

0

डिजाइन पैटर्न सीएस के लिए डिज़ाइन कक्षाओं में पढ़ाए जाते हैं। वे जरूरी नहीं हैं, लेकिन वास्तव में सहायक होते हैं यदि आप समान परिस्थितियों को हल करने के लिए समान समाधान ढूंढ सकते हैं।

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

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

पैटर्न के बारे में कुछ भी उल्लेखनीय नहीं है, सबसे अच्छी बात ये है कि वे ऐसे विचार हैं जिन्हें बार-बार उपयोगी तरीके से कैनन और परिभाषित किया जाता है।

2

मैं कहूंगा कि बहुत

डिजाइन पैटर्न के साथ चाल सीखने जहां और जब उन्हें उपयोग करने के लिए है। तो फिर आप के लिए चीजों के सभी प्रकार के कर सकते हैं की तरह है:

  1. अपने कोड अधिक पठनीय
  2. यह आसान बनाए रखने के लिए
  3. यह और अधिक लचीला
  4. बनाओ बनाएं और सूची पर चला जाता है ...

लेकिन कभी कभी वे अपने को जानने के कैसे और कब फिर से वहाँ लाभ में से कुछ के ठीक विपरीत कर सकते हैं ...

क्या आपने कभी एक फ़्रेमिंग हथौड़ा के साथ एक स्लीवर खींचने की कोशिश की है? तुमसे प्यार हो सकता है आप हथौड़ा तैयार लेकिन इसकी समस्याओं के सभी प्रकार पैदा करने के लिए जा रहा है अगर आप इसे इस तरह से इस्तेमाल करने की कोशिश ...

मुझे लगता है कि के रूप में आप refactor आप कोड है कि यह कभी कभी एक खास पैटर्न में विकसित या आप हो सकता है इसे महसूस किए बिना सभी पैटर्न का उपयोग कर रहे हैं।

+2

मेरे अनुभव में, डेवलपर्स जो डिजाइन पैटर्न के बारे में सोचते हैं, वे विपरीत प्रभावों को और अधिक बार प्राप्त करते हैं। –

+1

मैं सहमत हूं ... मैं कहूंगा कि कोड लिखो ... फिर यदि संभव हो तो रिफैक्टर और यदि आवश्यक हो और जैसा कि मैंने कहा कि एक डिज़ाइन पैटर्न विकसित हो सकता है। लेकिन कभी-कभी डिज़ाइन के दौरान आप भी एक का उपयोग करने का अवसर देख सकते हैं। – bytebender

24

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

मैं कहूंगा कि उनका शुद्ध प्रभाव ऋणात्मक है, क्योंकि अवधारणा से मोहक लोगों द्वारा घृणास्पद ओवेरिनिनेरिंग और संभवतः उनके कोड में जितने संभव हो उतने पैटर्न को क्रैक करने की कोशिश कर रहा है। शायद Maslow's hammer प्रभाव भी खराब डिजाइन की ओर अग्रसर है क्योंकि इष्टतम को खोजने के बजाय, डेवलपर को एक डिज़ाइन पैटर्न याद आया जो (बुरी तरह से) फिट बैठता है।

+4

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

+3

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

+0

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

1

सॉफ्टवेयर पैटर्न महत्वपूर्ण हैं चाहे आप जानते हैं कि आप उनका उपयोग कर रहे हैं या नहीं ... परिभाषा के अनुसार।

एक डिज़ाइन पैटर्न आमतौर पर एक सामान्यीकृत समस्या का एक सामान्यीकृत, पुन: प्रयोज्य समाधान है।

आप या तो तब तक हैक कर सकते हैं जब तक आप सामना करने वाली हर समस्या का समाधान नहीं करते हैं या आप "पैटर्न" सीख सकते हैं कि प्रोग्रामर पीढ़ियों के लिए उपयोग कर रहे हैं। यदि आप सबसे सामान्य, नामित पैटर्न के बारे में अपने ज्ञान को औपचारिक रूप देते हैं, तो समाधानों पर चर्चा करने और लागू करने के लिए आपके पास एक सामान्य शब्दावली होगी।

का आनंद लें,

रॉबर्ट सी Cartaino

6

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

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

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

वास्तव में, अच्छा सॉफ्टवेयर एक डिजाइन है। और यदि डिजाइन अच्छा है, तो इसका शायद पुन: उपयोग किया जा सकता है। वोला - एक डिजाइन पैटर्न।

7

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

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

चेतावनीपूर्ण कहानी "कोर जावा ईई पैटर्न" किताब है। इसमें सामानों का एक गुच्छा सूचीबद्ध है जो ईजेबी 1.0 और 2.0 के लिए "सर्वोत्तम प्रथाओं" को संबोधित करता है जिन्हें अब विरोधी पैटर्न माना जाता है। ईजेबी 3.0 spec उनमें से बहुत से दूर करता है। वसंत बाकी की हत्या कर रहा है।

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

5

हालांकि कभी-कभी डिजाइन पैटर्न के बारे में बात करने में उपयोगी हो सकता है, लेकिन मैं उन लोगों से सहमत हूं जो उन्हें कई परिस्थितियों में हानिकारक मानते हैं।

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

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

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

2

मैं कहूंगा कि वे निश्चित रूप से महत्वपूर्ण हैं।

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

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

1

पैटर्न पर विचार करने से पहले सिद्धांतों के साथ शुरू करें, क्योंकि यह अत्यधिक प्रचलित डिजाइन सिद्धांत हैं जो पैटर्न के उभरने को सूचित करते हैं और प्रेरित करते हैं।

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

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

लिए एक अच्छा स्थान डिजाइन सिद्धांत के साथ शुरू करने के लिए Uncle Bob Martin's SOLID principles, उनके बारे में अच्छी बात यह है पर नजर डालना है, एक बार वे में डूब, कि तुम लगता है कि आप पहले से ही पता था कि उन्हें (जो आप स्मार्ट लगता है) और

है अंकल बॉब की पुस्तक Clean Code कुछ उपयोगी उदाहरणों के साथ समान सिद्धांतों को भी शामिल करती है, केवल सिद्धांतों को मूल लेखों के रूप में स्पष्ट रूप से उद्धृत नहीं करते हैं, आमतौर पर आपके कार्यों, कक्षाओं आदि को व्यवस्थित करने और व्यवस्थित करने पर अधिक ध्यान केंद्रित करते हैं।

0

ने डिज़ाइन पैटर्न पर टिप्पणी की उपयोगी हैं अगर आप ओपन सोर्स प्रोजेक्ट्स में योगदान करने की कोशिश कर रहे हैं ... पर्याप्त कहा!

संबंधित मुद्दे