टाइपिड कीवर्ड खराब डिज़ाइन का उपयोग क्यों किया जाता है?

Question

मैंने सुना है कि बहुत से लोग कहते हैं कि typeid का कोई भी उपयोग खराब डिज़ाइन है, फिर भी मेरे लिए ऐसा लगता है कि यह बहुत अच्छी उपयोगिता प्रदान करता है।

1. जब (और क्यों) typeid "खराब डिज़ाइन" का उपयोग होता है?
2. typeid का उपयोग कब स्वीकार्य है?
3. जब यह स्वीकार्य नहीं है, लेकिन आपको अभी भी कुछ समान की आवश्यकता है, तो क्या कोई विकल्प होगा जिसमें अच्छी डिजाइन होगी?

Answer 1

समस्या typeid के साथ नहीं है।

PolymorphicType *pType = ...; 
if(typeid(*pType) == typeid(Derived1)) 
    pType->Func1(); 
else if(typeid(*pType) == typeid(Derived2)) 
    pType->Func2(); 
else if(typeid(*pType) == typeid(Derived3)) 
    pType->Func3(); 

यह है कि हम क्या कॉल "वास्तव में बेवकूफ" है: समस्या यह है कि typeid देखकर यह लिखने के लिए प्रोत्साहित करते हैं है। यह एक वर्चुअल फ़ंक्शन कॉल है जो कम से कम उचित तरीके से संभव है। typeid में dynamic_cast और virtual फ़ंक्शंस को प्रतिस्थापित करने के लिए उपयोग किए जाने पर दुरुपयोग की संभावना है।

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

typeidकी अंतिम रिज़ॉर्ट की बहुलक प्रकार की कटौती विधि है।

क्या typeid का सभी उपयोग गलत है? बिलकूल नही। boost::any इसके बिना संभव नहीं होगा। वैसे यह संभव होगा, लेकिन यह void* से अधिक सुरक्षित नहीं होगा। typeid क्या टाइप-सुरक्षित boost::any प्रकार मिटा सकता है। इसके अन्य वैध उपयोग भी हैं।

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

टाइपिंग धीमा है?

सामान्य तौर पर, typeid कॉल करने के लिए मुख्य कारण या तो (boost::any के रूप में) टेम्प्लेटेड कोड या जब आप एक बहुरूपी प्रकार की उम्मीद कर रहे है। यदि प्रकार स्थिर रूप से निर्धारित होता है (यानी: एक टाइपनाम या गैर-पॉलीमोर्फिक प्रकार का मान दिया जाता है), तो आप संकलन-समय पर इसे करने की उम्मीद कर सकते हैं।

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

Answer 2

मुझे नहीं लगता कि कोई भी कहता है कि typeid का उपयोग स्वयं खराब डिजाइन है; बल्कि, आप जो सुनेंगे वह यह है कि typeid का उपयोग खराब डिजाइन के संकेत है। विचार यह है कि से Square को में उन वर्गों में अंतर करने वाले किसी तर्क को वर्चुअल फ़ंक्शन (पॉलिमॉर्फिज्म) द्वारा व्यक्त किया जाना चाहिए।

कहने की जरूरत नहीं है, यह एक पूर्ण नियम नहीं है।

Answer 3

यह बहुत बुरा है कि जिन्होंने आपको यह अच्छी सलाह दी है, वे इसके कारण नहीं दे सकते। इसका मतलब है कि वे cargo cult प्रोग्रामर सरल हैं।

सभी अभिव्यक्तियों में एक स्थिर संकलन-समय प्रकार (टेम्पलेट विस्तार के बाद) होता है। सभी प्रकार या तो polymorphic हैं या नहीं।

मैं तुम्हारे लिए विस्तृत करने क्यों typeid (के निकटतम बात) बेकार दोनों ही मामलों में है की कोशिश करेंगे:

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

2. यदि अभिव्यक्ति का स्थिर प्रकार polymorphic है, तो typeid विफल रहता है। हां, यह वस्तु के गतिशील प्रकार पर जानकारी देगा। लेकिन केवल सबसे व्युत्पन्न गतिशील प्रकार। यह लिस्कोव प्रतिस्थापन सिद्धांत का उल्लंघन करता है, क्योंकि दिए गए प्रकार Base और Child, Child से व्युत्पन्न एक नया प्रकार Grandchild को Child के रूप में नहीं माना जाएगा। ओपन-क्लोज़ेड सिद्धांत का भी उल्लंघन किया जाता है, क्योंकि डिज़ाइन को सभी प्रकार के पुनर्लेखन के बिना नए प्रकारों के साथ बढ़ाया नहीं जा सकता है। कोई encapsulation नहीं है, क्योंकि कक्षा पदानुक्रम के बारे में जानकारी मजबूत युग्मन बनाने, कार्यक्रम भर में बिखरे हुए होना चाहिए। dynamic_cast कुछ पर विजय प्राप्त करता है लेकिन इन सभी समस्याओं में से कुछ नहीं।

संक्षेप में, typeid का उपयोग करने वाला एक प्रोग्राम बनाए रखने और परीक्षण करने में बहुत मुश्किल होगा।

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