बॉब मार्टिन की पुस्तक "सिद्धांत, प्रतिमान, और तकनीक के विकास में C #" की आलोचना

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

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


पुस्तक के पहले पन्नों से, मार्टिन्स ने प्रशंसक को बहुत हल्के ढंग से फेंक दिया, पुस्तक को निम्नानुसार शुरू किया:

“मेरा अनुभव बताता है कि .NET प्रोग्रामर अक्सर जावा या C ++ में लिखने वालों की तुलना में कमजोर होते हैं। यह स्पष्ट है कि अपवाद हैं। हालांकि, बार-बार अपने श्रोताओं को देखते हुए, मुझे यह निष्कर्ष निकालने के लिए मजबूर होना पड़ा कि .NET प्रोग्रामर आमतौर पर सॉफ्टवेयर विकास विधियों, डिजाइन पैटर्न और सिद्धांतों, आदि से कम परिचित हैं। अक्सर ऐसा होता है कि मौजूद .NET प्रोग्रामर इन मूलभूत अवधारणाओं के बारे में बिल्कुल नहीं सुनते हैं। इस स्थिति को बदलना होगा ।

इस पुस्तक पर काम करते समय, मैंने अक्सर यह संदेह किया है कि क्या अपना नाम .NET को समर्पित पुस्तक के कवर पर रखा जाए। मैंने खुद से पूछा कि क्या मैं .NET से संबद्ध होना चाहता हूं और इस मंच से जुड़े सभी नकारात्मक विचारों के साथ। लेकिन इससे इनकार करने का क्या फायदा? मैं एक .NET प्रोग्रामर हूं। नहीं! मैं एक लचीला .NET प्रोग्रामर हूं। और इस पर गर्व है। ”

ठीक है, अब देखते हैं कि हम क्या कहते हैं। अनपढ़ .NET गाल, मार्टिन साथियों से सीख सकते हैं।

सिद्धांतों

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

यहाँ एक दिलचस्प बात है:

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

एक तरफ, यह बहुत ही व्यावहारिक दृष्टिकोण है, लेकिन दूसरी तरफ, आपको इस तरह के सख्त दिशानिर्देशों का पालन करने की आवश्यकता है कि अतिरिक्त नियमों को लागू करने के लिए कि कब और क्या नहीं करना चाहिए?

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

नीचे उन सिद्धांतों का वर्णन किया गया है जिनका केवल उल्लंघन नहीं किया जा सकता है।

LSP

"अगर हम एक व्युत्पन्न वर्ग बनाते समय बेस क्लास में बदलाव करने के लिए मजबूर होते हैं, तो संभवतः डिज़ाइन में कोई दोष है।"

या फिर एक और विकल्प है: हम एक वास्तविक दुनिया में रहते हैं जिसमें विकासवादी डिजाइन एक प्रमुख विकास दृष्टिकोण है।

“क्या एलएसपी का सिद्धांत वास्तविक कार्यक्रमों में अनुप्रयोग पाता है? एक परियोजना से लिया गया एक उदाहरण पर विचार करें जो मैंने कई साल पहले काम किया था । ... 1990 के दशक की शुरुआत में ... "
मूल पुस्तक 2006 के मध्य में जारी की गई थी (सी # 2.0 और सामान्यीकरण के बाद), और कुछ साल पहले - यह 1990 के दशक की शुरुआत है।

"LCP प्रतिस्थापन सिद्धांत OCP सिद्धांत को लागू करने के लिए मुख्य उपकरणों में से एक है।"
मैं कहूंगा कि OCP प्राप्त करने के लिए विकल्पों में से एक बहुरूपता है, और LSP कहता है कि बहुरूपता काम करता है जो हम उम्मीद करते हैं। ओसीपी प्राप्त करने के लिए अन्य विकल्प हैं, उदाहरण के लिए, कॉलबैक फ़ंक्शन के आधार पर।

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

DIP

इस सिद्धांत की एक अधिक विस्तृत आलोचना लेख "निर्भरता उलटा के सिद्धांत पर एक महत्वपूर्ण नज़र" में वर्णित है।

लेकिन यहाँ एक बहुत ही भावनात्मक निष्कर्ष है जो बहुत प्रसन्न था:

“वास्तव में, निर्भरता का ऐसा उलटा वस्तु उन्मुख डिजाइन का एक बड़ा संकेत है। इससे कोई फर्क नहीं पड़ता कि कार्यक्रम किस भाषा में लिखा गया है। यदि निर्भरताएं उलटी हैं, तो हमारे पास ऑब्जेक्ट-ओरिएंटेड डिज़ाइन है। अन्यथा, डिजाइन प्रक्रियात्मक है। "
बहुत विवादित बयान, सहमत!

ओसीपी

बहुत से लोग नहीं जानते हैं कि ओपन-क्लोज्ड सिद्धांत के लेखक बॉब मार्टिन नहीं हैं, लेकिन बर्ट्रेंड मेयर अपनी पुस्तक " ऑब्जेक्ट-ओरिएंटेड डिज़ाइन ऑफ़ सॉफ्टवेयर सिस्टम्स" में हैं । उसी समय, यहां तक ​​कि कम लोगों ने ध्यान दिया कि बॉब मार्टिन इस सिद्धांत की अपने तरीके से व्याख्या करते हैं।

बॉब मार्टिन से परिभाषा : सॉफ्टवेयर इकाइयां (कक्षाएं, मॉड्यूल, फ़ंक्शन, आदि) विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद।

इस प्रकार, मॉड्यूल की दो मुख्य विशेषताएं हैं:

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

बर्ट्रेंड मेयर से परिभाषा : मॉड्यूल खुले और बंद दोनों होने में सक्षम होना चाहिए।
इसके अलावा, खुलेपन और निकटता की अवधारणाओं को निम्नानुसार परिभाषित किया गया है:

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

दूसरे शब्दों में, मेयर मॉड्यूल के खुले / बंद इंटरफ़ेस के बारे में बात करता है, और मार्टिन, इसके इंटरफ़ेस और कार्यान्वयन सहित पूरे मॉड्यूल को खोलने / बंद करने के बारे में बात करता है।

पुनर्संयोजन के बिना मॉड्यूल के व्यवहार के विस्तार की संभावना को मॉड्यूल के लिए आवश्यकताओं में वर्णित किया जाना चाहिए, न कि सिद्धांतों पर आधारित होना चाहिए।

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

आईएसपी

पुस्तक को पढ़ते हुए, मैंने बार-बार खुद को यह सोचते हुए पाया कि पुस्तक खरोंच से नहीं लिखी गई है, बल्कि दूसरा संस्करण है, जिसके उदाहरण C # में अनुवादित हैं। इसके अलावा, पुस्तक को "माथे पर" फिर से बनाया गया है, और .NET प्लेटफ़ॉर्म के मुहावरों का उपयोग करके संसाधित नहीं किया गया है।

इस संपत्ति की सबसे अच्छी अभिव्यक्तियों में से एक इंटरफ़ेस अलगाव सिद्धांत के विवरण में दिए गए उदाहरण हैं।

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



इस बारे में लेखक ने क्या लिखा है: "यह समाधान आईएसपी सिद्धांत के अनुरूप है और डोर क्लाइंट और टाइमर वर्ग के बीच संबंध नहीं बनाता है। ... हालाँकि, यह बहुत सुंदर नहीं है। हर बार जब हम टाइमआउट रजिस्टर करना चाहते हैं, हमें एक नई वस्तु बनानी होगी। ”

इस खंड को पढ़ने के बाद, मैंने कल्पना की कि छोटे मार्टिन (जो .NET का बेटा है) को इसे पढ़ने के बाद क्या कहना है:

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

हालाँकि, स्पष्ट रूप से ऐसी कोई बातचीत नहीं थी! इसलिए, यह अध्याय बहुत खराब उदाहरण देता है जो एक सामान्य सी # एप्लिकेशन में नहीं पाया जा सकता है।

यूएमएल

"स्टेटिक आरेख एक कार्यक्रम की अपरिवर्तनीय तार्किक संरचना का वर्णन करते हैं, अर्थात् तत्व - वर्ग, वस्तुएं , डेटा संरचनाएं - और उनके बीच संबंध।"

ऑब्जेक्ट "किसी प्रोग्राम की अपरिवर्तनीय तार्किक संरचना" का हिस्सा नहीं हैं।

"एक संघ एक साधारण संबंध है, इस तथ्य में शामिल है कि एक वस्तु दूसरे के लिए लिंक रखती है और किसी अन्य वस्तु के तरीकों को बुलाती है।"

एसोसिएशन लिंक के संरक्षण का मतलब नहीं है। यदि क्लास ए सीधे सिंगलटन का उपयोग करता है, तो कोई लिंक नहीं है, लेकिन एक संघ है।

“रचना एकत्रीकरण का एक विशेष मामला है। फिर, मैं ध्यान देता हूं कि कार्यान्वयन एक सामान्य संघ से अप्रभेद्य है। इस बार, कारण यह है कि इस संबंध का C # कार्यक्रमों में कुछ उपयोग है । "

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

पैटर्न

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

मुखौटा और मध्यस्थ

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

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

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

डेकोरेटर

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

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

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

आगंतुक

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

जाहिर है, चयनित टुकड़ा केवल C ++ से C # में संक्रमण के बाद अद्यतन नहीं किया गया था।
"इससे भी बदतर, कास्टिंग की गति पदानुक्रम की चौड़ाई और गहराई पर निर्भर हो सकती है, और इसलिए यह भविष्यवाणी करना मुश्किल है।"

यह संभव है कि कार्यान्वयन के कई उत्तराधिकार वाले वातावरण के लिए, बड़ी पदानुक्रम जातियों के प्रदर्शन को प्रभावित कर सकते हैं, लेकिन मुझे .NET के लिए इन शब्दों का प्रमाण नहीं मिला।

राज्य

अध्याय 36 एक साधारण वेक्टर (प्रकार IList के क्षेत्र ) के आधार पर बनाई गई रूपांतरण तालिका पर चर्चा करता है, जो निम्नलिखित सलाह देता है:

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

खाका विधि और रणनीति

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

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

इकाई परीक्षण

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

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

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

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

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

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

नोट
मैंने इस लेख में इसके बारे में और अधिक लिखा "टेस्टेड डिज़ाइन बनाम। अच्छा डिजाइन । ”

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

भयानक परीक्षणों का अच्छा उदाहरण है

खैर, पुस्तक परीक्षणों का उदाहरण देती है जिसके लिए आपको कीबोर्ड का चयन करने की आवश्यकता होती है। यहाँ उनमें से एक है:

[Test] public void LoadingEmployeeDataCommand() { operation = new LoadEmployeeOperation(123, null); SqlCommand command = operation.LoadEmployeeCommand; Assert.AreEqual("select * from Employee " + "where EmpId=@EmpId", command.CommandText); Assert.AreEqual(123, command.Parameters["@EmpId"].Value); } 

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

नेट

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

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

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

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

PrimeGenerator

मार्टिन्स राज्य के बहुत शौकीन हैं, इसलिए जब एक प्राइम नंबर जनरेटर (पी। 80) को रिफैक्ट करते हुए, स्थिर क्षेत्रों को आवंटित किया गया था:

“तीन कार्यों के आवंटन ने मुझे कुछ स्थानीय चर वर्ग के स्थिर क्षेत्रों में बदल दिया। नतीजतन, यह बहुत स्पष्ट हो गया कि कौन से चर वास्तव में स्थानीय हैं और जिनकी व्यापक गुंजाइश है। "

 class PrimeGenerator { private static bool[] crossedOut; private static int[] result; public static int[] GeneratePrimeNumbers(int maxValue) { return null; } //    crossedOut private static void UncrossIntegersUpTo(int maxValue) { } //  result   crossedOut private static void PutUncrossedIntegersIntoResult() { } } 

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

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

मैं यह नहीं कह रहा हूँ कि कोड इस पुस्तक के विमोचन से एक साल पहले निकले हुए पुनरावृत्त खंडों का उपयोग नहीं करता है।

SocketServer

यह कोड 251 पेज पर चर्चा की गई है और किताब के साथ आने वाले उदाहरणों में नहीं है। मैंने इसे यहां रखा है ।

 public interface SocketService { void Serve(Socket s); } public class SocketServer { private TcpListener serverSocket = null; private Thread serverThread = null; private bool running = false; private SocketService itsService = null; private ArrayList threads = new ArrayList(); public SocketServer(int port, SocketService service) { itsService = service; IPAddress addr = IPAddress.Parse("127.0.0.1"); serverSocket = new TcpListener(addr, port); serverThread = new Thread(new ThreadStart(Server)); serverThread.Start(); } public void Close() { running = false; serverThread.Interrupt(); serverSocket.Stop(); serverThread.Join(); WaitForServiceThreads(); } private void Server() { serverSocket.Start(); running = true; while (running) { Socket s = serverSocket.AcceptSocket(); StartServiceThread(s); } } //   } 

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

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

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

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

ट्री-मैप

पूरे कोड को यहां देखा जा सकता है ।

 internal class TreeMapNode { private static readonly int LESS = 0; private static readonly int GREATER = 1; private IComparable key; private object value; private TreeMapNode[] nodes = new TreeMapNode[2]; private int SelectSubNode(IComparable key) { return (key.CompareTo(this.key) < 0) ? LESS : GREATER; } } 

यहां सब कुछ इतना घातक नहीं है, लेकिन जावा-शैली के स्थिरांक का उपयोग, कुंजी और नोड्स फ़ील्ड के लिए आसानी से कीवर्ड का अभाव, साथ ही असफल निरंतर नाम: LESS और GREATER , जो वास्तव में, उप-सूचकांक का निर्धारण करते हैं, हड़ताली हैं।

निष्कर्ष

मुझे एक बार पूछा गया था कि मैंने 2 बिंदुओं पर goodreads.com पर यह पुस्तक क्यों रेट की है। खैर, इस मामले में, मेरे पास एक काउंटर सवाल है: क्या यह वास्तव में अधिक डालने लायक है?

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

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