बिल वैगनर की किताब इफेक्टिव सी # के बारे में

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

यद्यपि ये पुस्तकें पाठक के लिए स्वर्ग हैं, लेकिन इन्हें लिखना अविश्वसनीय रूप से कठिन है। इसे समझने के लिए, बस श्रृंखला से एक लेख लिखने का प्रयास करें "C # भाषा के इस फीचर का उपयोग / उपयोग न करें" या अपनी टीम में कुछ होली-चोर को याद रखें, जो एक निर्दोष वाक्यांश के साथ शुरू हुआ था, लेकिन हर जगह कास्ट ऑपरेटर के बजाय का उपयोग करें। “या इसी तरह का एक और वाक्यांश।

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

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

इसीलिए जब श्रृंखला को पढ़ने (या सुनने) से, कुछ करने या न करने की सलाह दी जाती है, तो आपको इस सलाह के कारण को समझने की कोशिश करने की जरूरत है। यह आपको इस सलाह को संक्षेप में प्रस्तुत करने और व्यापक संदर्भ में उपयोग करने की अनुमति देगा, और, कम महत्वपूर्ण नहीं, यह आपको इस सलाह का पालन करने की समझ देगा और जब इसे तोड़ने का समय होगा!
यह अनुमान लगाना आसान है कि यदि प्रभावी C # के बारे में मेरे कोई प्रश्न नहीं हैं, तो मैं यह सब नहीं लिखूंगा। मेरे खेद के लिए, ये मुद्दे मेरी अपेक्षा से बहुत अधिक निकले।

"छोटा" अशुद्धि

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

अशुद्धि # 1। स्थैतिक तरीकों पर काबू पाने
"आप स्थैतिक Object.Reference और static Object.Equals () को कभी भी ओवरराइड नहीं करते क्योंकि वे रनटाइम प्रकार की परवाह किए बिना सही परीक्षण प्रदान करते हैं।"

लेखक कई बार लिखता है कि स्थिर तरीकों को फिर से परिभाषित करने (ओवरराइड या रीडिफाइन) करने की कोई आवश्यकता नहीं है, क्योंकि वे उचित तरीके से व्यवहार करते हैं। एकमात्र समस्या यह है कि हम C # में ऐसा नहीं कर सकते।

कोई भी लेख या पुस्तक एक तरह का "अमूर्त" होता है, जो अनावश्यक विवरणों को छोड़ते हुए मुख्य विशेषताओं पर केंद्रित होता है। कठिनाई इस तथ्य में निहित है कि यह "अमूर्त" महत्वपूर्ण पहलुओं को प्रभावित नहीं करता है।

अशुद्धि # 2। स्थानीय चर जीवनकाल

सभी संदर्भ प्रकार, यहां तक ​​कि स्थानीय चर, ढेर पर आवंटित किए जाते हैं। फ़ंक्शन से बाहर निकलते ही एक संदर्भ प्रकार का प्रत्येक स्थानीय चर कचरा बन जाता है।

कचरा कलेक्टर अधिक जटिल है जितना कि यह प्रतीत हो सकता है और विधि पूरा होने से पहले स्थानीय चर कलेक्टर द्वारा पुनः प्राप्त किया जा सकता है!

अशुद्धि # ३ । ऑपरेटर के बारे में ==

"कोई बात नहीं क्या प्रकार शामिल है, एक == हमेशा सच है।"

वास्तव में, .NET प्लेटफ़ॉर्म के लिए, यह नियम हमेशा लागू नहीं होता है। क्या आप एक उदाहरण दे सकते हैं जब इस स्थिति का उल्लंघन किया जाता है?

अशुद्धि # 4। इंटरफ़ेस आभासीता

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

मैं सहमत हूं कि इंटरफ़ेस वंशानुक्रम की अपनी विशेषताएं हैं। हां, इंटरफ़ेस विधि का कोई भी कार्यान्वयन स्पष्ट रूप से "सील" होगा, लेकिन यह एक विधि की एक विशेषता है जो एक इंटरफ़ेस विधि को लागू करता है, न कि स्वयं इंटरफ़ेस।

अशुद्धि # 5। ऑब्जेक्ट क्रिएशन प्रोसीजर

"यहाँ प्रकार के पहले उदाहरण के निर्माण के लिए संचालन का क्रम दिया गया है:

1. स्थैतिक चर भंडारण 0 पर सेट है।
2. स्टेटिक वैरिएबल इनिशियलाइज़र निष्पादित करते हैं।
3. बेस क्लास के लिए स्टेटिक कंस्ट्रक्टर निष्पादित होते हैं।
4. स्थिर कंस्ट्रक्टर निष्पादित करता है।
5. ... "

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

लेकिन अगर पिछले अशुद्धियों को मेरी साक्षरता के लिए जिम्मेदार ठहराया जा सकता है, तो कई और गंभीर बिंदु हैं।

अशुद्धि # 6। संग्रह पुनरावृत्तियों के बारे में

काउंसिल 21 में, संग्रह संग्रहकर्ताओं को लागू करने के लिए लेखक निजी आंतरिक कक्षाओं का उपयोग करने का एक अद्भुत उदाहरण प्रदान करता है। इस दृष्टिकोण की पुष्टि के रूप में, निम्नलिखित उद्धरण दिया गया है:

".NET फ्रेमवर्क डिजाइनरों ने अन्य संग्रह कक्षाओं के साथ एक ही पैटर्न का पालन किया: डिक्शनरी <टी> में एक निजी डिक्शनरीमीटर <टी>, क्यू <टी> में एक क्यूएएन्यूमेररेटर <टी> शामिल है, और इसी तरह। एनुमरेटर वर्ग का निजी होना कई फायदे देता है ... "

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

मैं समझ सकता हूं कि क्या यह उदाहरण काल्पनिक था (क्योंकि यह उदाहरण अपने स्वयं के संग्रह के लिए इतना बुरा नहीं है)। लेकिन प्रभावी C # नामक पुस्तक में, इस तरह की स्वतंत्रता और त्रुटियाँ मुझे बहुत अजीब लगती हैं।

अशुद्धि # 7। बराबरी और GetHashCode के बारे में

इक्वल्स और गेटहैशकोड विधियों के बहुत सारे प्रश्न हैं ( Inaccuracy # 3 भी इस क्षेत्र से है, वैसे, प्रश्न का मेरा उत्तर यह है: यह Double.NaN है)।

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

इसलिए, उदाहरण के लिए, लेखक GetHashCode विधि को ओवरराइड करने की आवश्यकता के बारे में निम्नलिखित लिखता है:

"संदर्भ प्रकारों के लिए, यह काम करता है लेकिन अक्षम है। मूल्य प्रकारों के लिए, बेस क्लास संस्करण अक्सर गलत होता है । "

लेखक के दृष्टिकोण से Object.GetHashCode पद्धति की अक्षमता को निम्नलिखित द्वारा समझाया गया है। ऑब्जेक्ट के लिए GetHashCode मान एक आंतरिक काउंटर का उपयोग करता है, जो प्रत्येक ऑब्जेक्ट के निर्मित होने पर बढ़ता है। चूंकि काउंटर वैल्यू यादृच्छिक नहीं है, परिणामी हैश कोड लगातार टकराव और खराब खोज दक्षता को जन्म देगा।

सरल प्रयोगों से पता चलता है कि सीएलआर कुछ अलग तरह से व्यवहार करता है (कॉलिंग (नई वस्तु))। GetHashCode () दो बार पूरी तरह से अलग-अलग मूल्यों में परिणाम)। एक त्वरित Google साबित करता है कि कार्यान्वयन कुछ अधिक जटिल है।

कथन का दूसरा भाग और भी अजनबी है। वास्तव में, यहां तक ​​कि GetHashCode 42 को वापस लाने का तरीका सही है। हां, अप्रभावी, लेकिन बिल्कुल सही। इस बार, लेखक जोर देकर कहता है कि ValueType.GetHashCode पद्धति का कार्यान्वयन केवल पहले फ़ील्ड का हैश कोड लौटाता है। यह लगभग मामला है, और डिफ़ॉल्ट कार्यान्वयन पहले फ़ील्ड का रूपांतरित हैश कोड वापस कर सकता है। हां, इस कार्यान्वयन से बड़ी संख्या में टकराव हो सकते हैं, लेकिन इसे किसी भी तरह से गलत नहीं कहा जा सकता है।

वैसे भी, अगर हम इस तरह के कार्यान्वयन विवरण में आते हैं, तो उन्हें और अधिक विस्तार से चित्रित करना बेहतर होता है, न केवल वर्तमान व्यवहार, बल्कि ऐसे कार्यान्वयन के कारणों को भी समझाता है।

क्या वास्तव में सब कुछ इतना बुरा है?

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

नोट
यदि सब कुछ इतना अस्पष्ट है, तो यह पुस्तक C # /। NET पर क्लासिक पुस्तकों की सूची क्या बनाती है? मैं ईमानदारी से स्वीकार करता हूं कि मेरी राय इस पुस्तक के पहले संस्करण पर आधारित थी, जो लगभग 4-5 साल पहले पढ़ी गई थी। अगर मैंने आज यह सूची बनाई तो क्या मैं इसे जोड़ूंगा? यकीन नहीं हुआ ना! फिर भी, यह अपूर्ण प्रदर्शन के साथ अपनी तरह की एक अनूठी किताब है। इसलिए, जब तक बाजार पर एक वास्तविक प्रतिस्थापन दिखाई नहीं देता, तब तक मैं इसे इस सूची से नहीं हटाऊंगा।

रेटिंग: ३